Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi, I'm in the middle of evaluating DRBD together with SSD's, and so far it looks fairly good. However I have a few questions. The setup is as follows: Two hosts with an SSD on each, sychronized with DRBD. On top of DRBD I have (at the moment) an ext3 filesystem, and a linux kernel that does not support TRIM (I will not go into the discussion about why we have such an old kernel, the reasons are not technical). This will change in the future. 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 ? 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 ? br Håkan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20111115/0260e25f/attachment.htm>