[DRBD-user] DRBD SSD's and TRIM

Håkan Engblom zyber_cynic at hotmail.com
Tue Nov 15 13:04:06 CET 2011

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>

More information about the drbd-user mailing list