[colug-432] question about SSD wear

[Rob Funk]

Sorry, catching up on a week of email....

On Friday, September 9, 2016 8:40:31 AM EDT Johnathon Scott wrote:
> It probably doesn't matter at all in this use case but this discussion
> made me wonder whether file system choice has an effect on the life of
> SSDs.

It probably doesn't have as much of an effect as you might think, because 
the wear-leveling happens in the SSD firmware. By now, SSD firmware is pretty 
mature and very smart about masking the quirks of the hardware.

> So unless the disk is mounted with "noatime" option,
> each time a file object is accessed, metadata is written to the
> coresponding inode.

That's no longer true. The "relatime" option was invented to fix this 
situation without losing the atime functionality. With relatime, the system 
updates atime only if the old atime was older than the current mtime or 
ctime. This preserves the most common uses of atime (particularly regarding 
the mail spool), while drastically reducing the need to update it. And 
according to the mount(8) man page, relatime has been the default since 
Linux 2.6.30.

> Am I correct in my understanding that log-structured file systems like
> F2FS, LogFS, and ZFS (I might be wrong on ZFS considering ZIL/L2ARC)
> don't do this?  Updates are not stored in the exact same physical
> location.

"Exact physical location" has been a fiction in disks for a long time, even 
before SSDs, due to performance optimization and bad-sector handling. SSDs 
just make it more important for the fiction and reality to differ. The SSD 
firmware will do something like this log-structuring internally, although a 
log-structured fs will probably help for small writes.

My understanding is that it's still a good idea to minimize writes and to 
pay attention to the erase-block size. Support for the TRIM command helps a 
lot. But for most purposes the firmware insulates you from the SSD quirks.

https://en.wikipedia.org/wiki/Solid-state_drive#Suitable_file_systems