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. Regards, Phil