4 ms·
Also you can add noatime,nodiratime,discard to the options of your fstab config. But if you don't have SATA 3.1 or higher then don't use the discard option but
by logn 11y ago
Also you can add noatime,nodiratime,discard to the options of your fstab config. But if you don't have SATA 3.1 or higher then don't use the discard option but instead add fstrim <path> to a chron job or rc.local. The other options I mentioned turn off recording of access times to files/dirs.
And you can set the noop scheduler using echo noop > /sys/block/<device e.g. sda>/queue/scheduler. Whether that's the best option for you depends, but if you have an SSD it might be.
Finally if you're using full disk software encryption, do check if your SSD supports hardware-level encryption instead and if your BIOS allows you to set its key.
- agumonkey 11y agoAny reference about the 'no discard' advice ? I used it for a while on an Intel 520 80GB SSD, it was fine at first but when I reached low free space (~1GB) the SSD became sluggish, which isn't unexpected, but even after freeing 4GB it was still slow. Manually trimming reported '0 Bytes trimmed'. Only after remounting the disk without `discard` and then `fstrim --all` that the SSD got decent performances back.
- logn 11y agoI'd guess your SSD was doing a synchronous discard which would be slow. I know anything less than SATA 3.1 does it synchronously, and maybe there are other situations too. E.g., maybe async trimming requires a decent amount of free space?
- agumonkey 11y agoIt was fine before I reach low free space and I don't have SATA 3.1, not even 3, possible 1 lol, so it was synchronous ? I guess the controller needs some temporary space to do its magic and below that point it will struggle. The odd fact is that freeing space didn't allow for normal behavior until "forcing" an actual trim.
- aruggirello 11y agoI've always felt adding things like noatime or relatime was a bit too hacky. I'm not sure the actual consequences of access times not being properly recorded are well understood, and that scares me a lot; just exactly which software is actually affected (and how?). I don't use Mutt...but what about Samba? I have several folders shared in my LAN via Samba, with things like Access databases, Excel spreadsheets... could someone elaborate on this?
- pflanze 11y agoI've been using noatime forever (since 2002 or so) on my laptops/desktops and IIRC also all the servers that I set up myself, and a couple other servers I just checked have relatime (Debian default?), without any issue, although all of those machines only ran software of my choice and thus a relatively limited range. I even started somewhat relying on atime being the (otherwise non-existant at the time) "inode creation time" when using 'noatime', and was a bit upset when I realized that mounts created with "mount --bind" would lose the noatime setting (an explicit "mount -o remount,noatime" is required on the new mount point). I also used Samba around 2002, but am not sure whether I used noatime already with it.
- joosters 11y agoI've used it for years and never noticed a single problem. Mutt seems to be the only program that anyone ever mentions with an issue (it apparently uses the last access time to determine if a folder has received new mail since you last looked at it). Since I'm not a mutt user, I've no idea if anyone has bothered to fix this. IMO a file's last access time is inherently unreliable anyway, a file could have been read by a backup process or file indexer at any time. Your file browser might well peek at every file in a folder to make thumbnails or determine file types. You likely won't see any problems with Samba or with office documents, these all work fine with filesystems that don't have last access times at all (and Windows disabled last access times in Vista onwards, apparently)
- JoshTriplett 11y agonoatime implies nodiratime; you don't need both.