On July 13, 2014 7:05:48 AM EDT, Olav Reinert <seroton10@gmail.com> wrote:
On Friday 11 July 2014 15.17:46 Greg Freemyer wrote:
On Fri, Jul 11, 2014 at 2:40 PM, Olav Reinert <seroton10@gmail.com> wrote:
I have two SSD in a machine running a fully updated openSUSE 13.1.
blackbox:~ # hdparm -I /dev/sda | grep TRIM
* Data Set Management TRIM supported (limit 8 blocks) * Deterministic read ZEROs after TRIM
blackbox:~ # hdparm -I /dev/sde | grep TRIM
* Data Set Management TRIM supported (limit 8 blocks) * Deterministic read data after TRIM
Your first drive says that for that last read command it will return zeros always.
Your second drive says that for that last read command it "may" return something other than zeros, but if it does it will keep track of what it returned and always deterministicly return for future reads.
The ATA spec provides the drive a way to report which of the above 2 behaviors it follows. Both hdparm and lsblk are simply interpreting what the drive is saying and letting you know what the drive is saying is its behavior.
I did in fact overlook the slight difference in wording of the second TRIM- related message produced by hdparm. Thank you for your explanation - it makes sense now that lsblk reports the way it does.
Is there a way of checking whether TRIM-requests are actually sent to the drive? For example, is there a counter somewhere I can look at, similar to the counters for blocks read and written?
If there is, I don't know it. Fyi: most ssd drives treat trim as a synchronous command and flush the cache when it is processed. That has large negative performance effect if issued interspersed with normal I/o patterns. You can use fstrim called via cron to trim the filesystem during idle periods. Some newer drives support asynchronous trim, but I don't know how to tell which drives support it. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org