Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Thank,s for the quick reply. Just the info I needed. A follow up question: Do you have any roadmap for when a DRBD with TRIM-support will be available ? br Håkan > From: philipp.marek at linbit.com > To: drbd-user at lists.linbit.com > Subject: Re: [DRBD-user] DRBD SSD's and TRIM > Date: Tue, 15 Nov 2011 12:04:54 +0100 > CC: zyber_cynic at hotmail.com > > Hello Håkan! > > > 1. During a total synchronization of all data from primary to secondary, > > the entire area for that particular partition will be written on the > > secondary host/SSD. This is a bad thing to do with an SSD's since it > > will conclude every block on the disk is occupied by "useful" data, and > > it will have a large negative impact on the SSD's wear leveling > > algorithm. Can somebody confim this conclusion ? > Well, you can easily avoid the initial sync; as "unused" blocks will be > returned as zeroes it won't cause "different" data on both sides. > > See http://www.drbd.org/users-guide/re-drbdsetup.html#id486667 > for more details. > > > > 2. Even if TRIM is supported by the linux kernel (by use of newer kernel > > and a new filesystem), I doubt that it will be useful through DRBD. As > > far as I can see, TRIM is realized by sending ATA-commands to the > > SSD-device, telling it which blocks that are actually erased and does > > not contain valuable data. The only one who "knows" this is the > > filesystem in the kernel, and normally (when TRIM is in use) the > > information is passed from the filesystem to the device/partition it is > > mounted on, the SSD. However when DRBD is in between it is not obvious > > that these ATA-commands can go transparently through DRBD, especially > > not to the secondary DRBD-node (if so the "ATA TRIM"-command would have > > to travel within the DRBD-protocol, acrross the network, to the > > secondary node, and I strongly doubt it does). Is this a correct > > assumption, and is there a way to solve this problem ? > Yes, wait for a DRBD that supports TRIM. > > In the meantime you _might_ have luck with taking a node in StandAlone (to > prevent data changes), and run some offline TRIM tool that understands the > filesystem in use. > > > Regards, > > Phil -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20111115/61ef9539/attachment.htm>