<div dir="ltr">Hi.<br><div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/8/27 David Brown <span dir="ltr"><<a href="mailto:david@westcontrol.com" target="_blank">david@westcontrol.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The answer is quite simple - don't use "discard" mounts. They make your<br>
SSD much slower, especially for metadata-heavy operations.<br></blockquote><div><br></div><div>I tend to disagree with this.<br><br>On the writing operations I saw at least 2x speed with discard / TRIM enabled on dm-crypt LUKS partition.<br>
<br></div><div>On the another note it's not secure to use TRIM on dm-crypt, because attacker might identify which blocks are free and potentially can detect filesystem. <br><br></div><div>The fix for dm-crypt devices only will be in 3.1.x mainline, so don't think it's gonna be ported in the current 2.6.32 branch.<br>
<br><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The problem is that the halfwits that added TRIM to the SATA<br>
specifications made it a synchronous operation, so it blocks all queues<br>
and buffers. They also failed to give it proper semantics, such as<br>
specifying that reading from a TRIM'ed sector would give all zeros. If<br>
the people behind this nonsense had read the SCSI specifications for the<br>
equivalent operation, they would have made a much better TRIM that was<br>
asynchronous, could be queued, and would guarantee reading all zeros<br>
from a TRIM'ed block - which would have been much more useful.<br></blockquote><div><br></div><div>Well, if you won't use TRIM, you'll see in the future write performance degraded all because of the SSD internals. <br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Off-line TRIM using fstrim is useful, but not essential if you have<br>
bought a half-decent SSD that is not too small, and not too old. So use<br>
fstrim if it works on your setup - but don't worry if it doesn't. It's<br>
very unlikely that you will notice the difference.<br></blockquote><div><br></div><div>I read about it, but don't think it's a proper solution, I'm thinking about trying another virtualization technology instead. <br>
<br></div><div>LXC seems to be unstable for production yet. <br><br>Thinking about trying XEN on the more recent kernel.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Hope that helps,<br>
<br>
David<br>
<div class=""><div class="h5"><br>
<br>
<br>
On 27/08/13 17:10, spameden wrote:<br>
> is it implemented?<br>
><br>
> I've tried on 3.2.0-4 debian wheezy default kernel it's working just fine:<br>
> # dmsetup table<br>
> vg0-home: 0 443277312 linear 9:1 25166208<br>
> home: 0 443273216 crypt aes-cbc-plain<br>
> 0000000000000000000000000000000000000000000000000000000000000000 0 253:2<br>
> 4096 1 allow_discards<br>
><br>
> But not on OpenVZ's 2.6.32.xxxx:<br>
> # dmsetup table<br>
> vg0-home: 0 443277312 linear 9:1 25166208<br>
> home: 0 443273216 crypt aes-cbc-plain<br>
> 0000000000000000000000000000000000000000000000000000000000000000 0 253:2<br>
> 4096<br>
> vg0-swap: 0 4194304 linear 9:1 20971904<br>
> vg0-root: 0 20971520 linear 9:1 384<br>
><br>
><br>
><br>
><br>
><br>
</div></div><div class=""><div class="h5">> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@openvz.org">Users@openvz.org</a><br>
> <a href="https://lists.openvz.org/mailman/listinfo/users" target="_blank">https://lists.openvz.org/mailman/listinfo/users</a><br>
><br>
<br>
</div></div></blockquote></div><br></div></div></div>