The answer is quite simple - don't use "discard" mounts. They make your SSD much slower, especially for metadata-heavy operations.
The problem is that the halfwits that added TRIM to the SATA specifications made it a synchronous operation, so it blocks all queues and buffers. They also failed to give it proper semantics, such as specifying that reading from a TRIM'ed sector would give all zeros. If the people behind this nonsense had read the SCSI specifications for the equivalent operation, they would have made a much better TRIM that was asynchronous, could be queued, and would guarantee reading all zeros from a TRIM'ed block - which would have been much more useful. Off-line TRIM using fstrim is useful, but not essential if you have bought a half-decent SSD that is not too small, and not too old. So use fstrim if it works on your setup - but don't worry if it doesn't. It's very unlikely that you will notice the difference. Hope that helps, David On 27/08/13 17:10, spameden wrote: > is it implemented? > > I've tried on 3.2.0-4 debian wheezy default kernel it's working just fine: > # dmsetup table > vg0-home: 0 443277312 linear 9:1 25166208 > home: 0 443273216 crypt aes-cbc-plain > 0000000000000000000000000000000000000000000000000000000000000000 0 253:2 > 4096 1 allow_discards > > But not on OpenVZ's 2.6.32.xxxx: > # dmsetup table > vg0-home: 0 443277312 linear 9:1 25166208 > home: 0 443273216 crypt aes-cbc-plain > 0000000000000000000000000000000000000000000000000000000000000000 0 253:2 > 4096 > vg0-swap: 0 4194304 linear 9:1 20971904 > vg0-root: 0 20971520 linear 9:1 384 > > > > > > _______________________________________________ > Users mailing list > [email protected] > https://lists.openvz.org/mailman/listinfo/users > _______________________________________________ Users mailing list [email protected] https://lists.openvz.org/mailman/listinfo/users
