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 --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk