<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body><div><div style="font-family: Calibri,sans-serif; font-size: 11pt;">Thanks for taking the time to write out such an excellent answer, Rob!<br><br>Johnathon</div></div><div dir="ltr"><hr><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">From: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:rfunk@funknet.net">Rob Funk</a></span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Sent: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;">9/16/2016 11:33</span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">To: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:colug-432@colug.net">Central OH Linux User Group - 432xx</a></span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Subject: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;">Re: [colug-432] question about SSD wear</span><br><br></div>Sorry, catching up on a week of email....<br><br>On Friday, September 9, 2016 8:40:31 AM EDT Johnathon Scott wrote:<br>> It probably doesn't matter at all in this use case but this discussion<br>> made me wonder whether file system choice has an effect on the life of<br>> SSDs.<br><br>It probably doesn't have as much of an effect as you might think, because <br>the wear-leveling happens in the SSD firmware. By now, SSD firmware is pretty <br>mature and very smart about masking the quirks of the hardware.<br><br>> So unless the disk is mounted with "noatime" option,<br>> each time a file object is accessed, metadata is written to the<br>> coresponding inode.<br><br>That's no longer true. The "relatime" option was invented to fix this <br>situation without losing the atime functionality. With relatime, the system <br>updates atime only if the old atime was older than the current mtime or <br>ctime. This preserves the most common uses of atime (particularly regarding <br>the mail spool), while drastically reducing the need to update it. And <br>according to the mount(8) man page, relatime has been the default since <br>Linux 2.6.30.<br><br>> Am I correct in my understanding that log-structured file systems like<br>> F2FS, LogFS, and ZFS (I might be wrong on ZFS considering ZIL/L2ARC)<br>> don't do this? Updates are not stored in the exact same physical<br>> location.<br><br>"Exact physical location" has been a fiction in disks for a long time, even <br>before SSDs, due to performance optimization and bad-sector handling. SSDs <br>just make it more important for the fiction and reality to differ. The SSD <br>firmware will do something like this log-structuring internally, although a <br>log-structured fs will probably help for small writes.<br><br>My understanding is that it's still a good idea to minimize writes and to <br>pay attention to the erase-block size. Support for the TRIM command helps a <br>lot. But for most purposes the firmware insulates you from the SSD quirks.<br><br>https://en.wikipedia.org/wiki/Solid-state_drive#Suitable_file_systems<br><br><br>_______________________________________________<br>colug-432 mailing list<br>colug-432@colug.net<br>http://lists.colug.net/mailman/listinfo/colug-432<br></body></html>