[GTALUG] War Story: Asus UX305ca SSD failures

[Lennart Sorensen]

On Tue, Aug 06, 2019 at 12:14:35PM -0400, D. Hugh Redelmeier via talk wrote:
> There is the invisible problem of "write amplification".  Does write
> amplification count against the official endurance specifications?  If
> so, the user can have no real idea of where they are on the odometer.

That is true, and I suspect it does count, although they may have taken
some into account in the specs.

> Write amplification can get pathologically bad if the drive controller
> thinks that the disk is close to full.
> 
> - manufacturers always "overprovision".  They provide more flash
>   memory than is in the view of the disk that the computer sees.  That
>   prevents the drive actually from filling up.  I presume that cheaper
>   drives have less overprovisioning.  The amount of overprovisioning
>   isn't something disclosed on spec sheets.

I think that is part of why you get a 1TB consumer drive but a 960GB
enterprise drive.  Internally they are likely the same amount of actual
flash blocks.

> - using "trim" (see fstrim(8)) can inform the drive controller of
>   blocks that the filesystem considers deleted.  This cannot be
>   inferred by the controller until the logical block is overwritten.
> 
> - the user can leave some of the disk space unused and this helps as
>   long as the controller knows that the space is unused.
> 
> Another thing that needlessly wears SSDs: updating access times in the
> inodes of open files.  This is needed for POSIX semantics but I think
> that modern Linux systems default to being lazy about those updates (a
> Good Thing).  I could be wrong about this -- I haven't checked.
> 
> A purely log-structued filesystem would probably be good for SSDs.

Might be.

-- 
Len Sorensen