[DRBD-user] DRBD SSD's and TRIM

Philipp Marek philipp.marek at linbit.com
Tue Nov 15 12:04:54 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.

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.



More information about the drbd-user mailing list