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