At the point NAND technology is nowadays, I don't think you should be reducing writes at the cost of potential data corruption...

Well, I do maintain backups of my personal data. Anything else (e.g. Slackware-current) can be reinstalled.

Backups are always good. But NAND is a lot more resilient than it used to be and can usually withstand 100s of TBs written, many will run into the PB range (my drive is rated for 700TBs and if I were to write 50GB/day, which I'm nowhere close to doing that, my drive would last me 38+ years before the NAND wears out). Getting rid of a journal that could prevent corruption to save on the little bit of writes to prolong the longevity even further than it already is just isn't worth it in my book.

But it is nice to have discussions so people can see both sides and make whatever decision is best for them. Discussions like these in the past is what led me to do all my research on SSDs and NAND.

This is a different case, but I use journaling on my FreeBSD install (UFS) and my SSDs are 3 years old but have a ton of life left when I run smartctl against them. Agree that SSD drive technology now has made them very reliable and long lasting.

Late Aadditional Information - relatime
 

Hey all, I found this thread very informative as I work to understand the NVME/SSD I just got in a new laptop and preparing to do a dedicated Slackware64-current installation. As I was confirming for my self that noatime and nodiratime where, in fact, /fstab options, not having used them before. It seems that nodiratime has been subsumed into noatime, making nodiratime redundant and unnecessary. I also came across the relatime option options-atime-vs-relatime, which is a mix of options which reduces SSD access traffic. I seems relevant to the previous discussion.

Looking at the man page for mount, it isn't that nodiratime has been subsumed, just that it is part of noatime. So, you're still able to specify nodiratime as a mount option, but if you specify noatime, it will automatically include nodiratime. I wasn't aware of this, so thanks!

This kinda just comes down to what you want on your drive. noatime will just mean that you'll never have updated access times, which I don't really care about on my system. I'm more interested in the modified times. But if access times are interesting to you, relatime kinda is a mix, where it will update the access times only if the access time is before the modified/changed time or the access time was more than 1 day ago. This is actually the default for all kernels (since 2.6.30). If you want access time updated every time, no matter what, you need to use the strictatime option.

There's a new option ("new" as in I just discovered it) : "lazytime". Basically, it means the sysadmin prefers speed over persistence, when it comes to a file's atime/ctime/mtime values, but the times should be updated when it's sensible to do so, 24 hours later at the longest.

Read the cached inode; update the cached inode; don't write to non-volatile storage without an immediate need.

The "lazytime" option is documented in mount(8).

UPDATE: I just did a network-intensive test, using rsync over NFS, with the NFS share on a Raspberry Pi mounted with "lazytime". The basics:

-- in an Xterm
-- and in SSH
-- all disk cache warmed as much as possible
-- tested over both IP v4 and v6

My initial impression is that "lazytime" does reduce disk I/O. I heard a lot less disk I/O (a.k.a. "thrashing"). It's un-scientific to say this, but I'll take that less-audible knocking-about as a good thing.