<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 22, 2017 at 4:13 PM, Mike Hodson <span dir="ltr"><<a href="mailto:mystica@gmail.com" target="_blank">mystica@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello again Marius,<div><br></div><div>Looking at the SMART data, it is indeed a Sandforce drive;  these have the added benefit of lessened write-cycles due to onboard LZO(or similar; its proprietary but seems like LZO to me) compression internal to the chipset firmware. </div><div><br></div><div>Thats where these 5 values come into play:</div><span class=""><div><br></div><div><div>231 SSD_Life_Left           0x0013   100   100   010    Pre-fail  Always       -       0</div><div>233 SandForce_Internal      0x0032   000   000   000    Old_age   Always       -       1445</div><div>234 SandForce_Internal      0x0032   000   000   000    Old_age   Always       -       729</div><div>241 Lifetime_Writes_GiB     0x0032   000   000   000    Old_age   Always       -       729</div><div>242 Lifetime_Reads_GiB      0x0032   000   000   000    Old_age   Always       -       189</div></div><div><br></div></span><div>233 is "actual bytes over the SATA Bus written"; 234 is "bytes after compression" and it should almost always match 241 "Lifetime Writes" which is directly to the NAND. Reads is even lower.</div><div><br></div><div>231 is the Sandforce numbered metric similar to the aforementioned 233 Media_Wearout_Indicator metric.  Different numbers, same basic principle.  You're still at 100/100 which is still "pretty close to new" in the grand scheme of things.</div><div><br></div><div>My own 60GB Sandforce drive has way more writes/reads than yours, nearly triple for 1/2 the amount of NAND Onboard. </div><div><br></div><div><span class=""><div>195 ECC_Uncorr_Error_Count  0x001c   120   120   000    Old_age   Offline      -       0/0</div></span><div>196 Reallocated_Event_Count 0x0033   100   100   000    Pre-fail  Always       -       0</div><span class=""><div>231 SSD_Life_Left           0x0013   100   100   010    Pre-fail  Always       -       0</div></span><div>233 SandForce_Internal      0x0000   000   000   000    Old_age   Offline      -       3520</div><div>234 SandForce_Internal      0x0032   000   000   000    Old_age   Always       -       3904</div><div>241 Lifetime_Writes_GiB     0x0032   000   000   000    Old_age   Always       -       3904</div><div>242 Lifetime_Reads_GiB      0x0032   000   000   000    Old_age   Always       -       10944</div><div><br></div></div><div>As this shows, my write-load hasn't been so easily LZO compressed, and internal wear-leveling has made the 'write amplification' about 1.1 the input bytes.  3.9TiB written to the flash, over its lifecycle with only 3.5 TiB of input data.   Yours shows the approximate 1/2 write reduction possible when the majority of files on the drive are textual or easily compressed.  I've written a lot of already-compressed data to the disk over its lifetime, doing many Gentoo package updates and compiles, which implies a ton of bz2/xz files written over the years. </div><div><br></div><div>Both of our 'worst case scenario' disks should still last long into next decade as long as the electronics don't die first :) </div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Mike</div><div><br></div></font></span></div><div class="gmail_extra"><br></div></blockquote><div>I should also mention the 2 other metrics I posted:  195 ECC errors, and 196 reallocated sector count.  These are the 2 values that will start to rise before 'actual' drive death due to NAND failure. Indeed the SSD_Life_Left metric is specifically a linear 'how many is the drive rated for / how many have occurred' erase-count equation.  </div><div><br></div><div>The spontaneous ECC errors and reallocations are more indicative to the NAND's actual health.  Having 0 of either, you're still doing fine. </div><div><br></div><div>Mike</div><div><br></div></div></div></div>