<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'>
Hi,<BR>
<BR>
> I believe that this is no problem at all, as it writes only zeros (if the <BR>> source disc is "really" empty).<BR>
Unfortunately, in our product, I cannot assume that the source disk is "filled with zeroes" in those parts of the disk that is "free".<BR>
<BR>
> Why I come to this conclusion? On SSD discs without trim support and no trim <BR>> utility from the vendor, it's a well known technique to use SecureErase and <BR>> write zeros all over the disc, to restore factory default <BR>> settings/performance for such discs. (and this works!)<BR>Thanks for this info, I was not 100 % sure this worked fine. However setting a disk to factory default by writing zeroes to the entire disk requires taking that disk out of service ofcourse. <BR>
This is also a problem in the product I work with. So the options are limited.<BR>
There are specific situations in our products life-cycle where this is possible to do, and there we already do it. <BR>
So maybe I can use this a "fallback remedy" to recover SSD perfromance.<BR>
<BR>
br Håkan<BR> <BR>
<DIV>
> From: christoph@iway.ch<BR>> To: drbd-user@lists.linbit.com<BR>> Date: Tue, 15 Nov 2011 12:21:29 +0100<BR>> Subject: [DRBD-user] Fw: DRBD SSD's and TRIM<BR>> <BR>> Hello Håkan<BR>> <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>> I believe that this is no problem at all, as it writes only zeros (if the <BR>> source disc is "really" empty). And any SSD should not taint the flash cells <BR>> if it sees that a complete erase block (I believe this is between 2MB and <BR>> 8MB on todays SSDs?) only consists of zeros.<BR>> <BR>> Why I come to this conclusion? On SSD discs without trim support and no trim <BR>> utility from the vendor, it's a well known technique to use SecureErase and <BR>> write zeros all over the disc, to restore factory default <BR>> settings/performance for such discs. (and this works!)<BR>> <BR>> regards<BR>> Christoph<BR>> <BR>> We're using SSDs in production systems for ~3 years now and had only <BR>> positive experiences so far. (we have way over hundred SSDs already deployed <BR>> in servers) <BR>> <BR>> _______________________________________________<BR>> drbd-user mailing list<BR>> drbd-user@lists.linbit.com<BR>> http://lists.linbit.com/mailman/listinfo/drbd-user<BR></DIV> </div></body>
</html>