Slackware - InstallationThis forum is for the discussion of installation issues with Slackware.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I also delete the ext4 journal on SSD, to reduce writes even more. ext4 can be tuned to be very flash-friendly, but this particular boost comes at the cost of fsck time in the event of system crash.
My 2¢.
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.
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.
It seems that nodiratime has been subsumed into noatime, making nodiratime redundant and unnecessary.
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!
Quote:
Originally Posted by bigfoot cascadia
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.
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.
Last edited by gus3; 12-24-2019 at 08:46 PM.
Reason: "lazytime" is proving good in initial tests!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.