I use ls -lu and find -atime quite frequently. I've also been using OpenBSD
as a desktop (with all the insane disk activity of a browser cache, temp
files, git, etc) while doing absolutely nothing special using SATA SSD
drives. I'm running Softraid crypto on one, running without softraid on the
other. No snazzy mount options outside the defaults. It's been as reliable
as any spinning rust I've used. You're keeping good backups regardless,
right? Because that protects you from many more likely failure modes than
wear-level-exhaustion on SSD.
On Sat, Feb 10, 2018 at 10:38 AM, <mar...@martinbrandenburg.com> wrote:
> > From tom.sm...@wirelessconnect.eu Sat Feb 10 11:28:46 2018
> > From: Tom Smyth <tom.sm...@wirelessconnect.eu>
> > Date: Sat, 10 Feb 2018 09:10:30 +0000
> > Subject: Re: For a FFS on an SSD, which of "-o" nil, "sync" &/ "softdep"
> is
> > more data-safe and fast?
> > To: mar...@martinbrandenburg.com
> >
> > Hi Martin... can you give a specific case where you have experienced
> > negative impacts from thevmount options i suggested...
> > It would be good to know...
>
> Well I don't run noatime, so I can't give specific examples.
>
> The point I was making is that noatime is a tradeoff. You give up
> adherence to POSIX and historical Unix behavior in exchange for
> performance and less disk wear.
>
> Now I will admit that programs that rely on atime updates are few and
> far between. It was always a bit niche. Nowadays, most software is
> written on Linux, and most Linux systems use relatime.
>
> It might be an acceptable tradeoff. To use the examples from the
> manpage, if you know you're not going run any programs that need it and
> that you'll never leave your laptop up for seven days or if you know
> your news server doesn't need it, go ahead and disable it.
>
> Just don't forget to consider it as a potential problem if you run into
> trouble.
>
> Here are some lines from /etc/daily. Without atime updates, it could
> delete files. (Some of these might get more frequent mtime or ctime
> updates which would bump the atime under noatime.)
>
> The second set might be uncommented on a big multiuser system to clear
> out /tmp since users don't. They might be a little irritated when the
> file they've been reading for the last day gets deleted.
>
> next_part "Removing scratch and junk files:"
> if [ -d /tmp -a ! -L /tmp ]; then
> cd /tmp && {
> find -x . \
> \( -path './ssh-*' -o -path ./.X11-unix -o -path ./.ICE-unix \
> -o -path './tmux-*' \) \
> -prune -o -type f -atime +7 -execdir rm -f -- {} \; 2>/dev/null
> find -x . -type d -mtime +1 ! -path ./vi.recover ! -path
> ./.X11-unix \
> ! -path ./.ICE-unix ! -name . \
> -execdir rmdir -- {} \; >/dev/null 2>&1; }
> fi
>
> # Additional junk directory cleanup would go like this:
> #if [ -d /scratch -a ! -L /scratch ]; then
> # cd /scratch && {
> # find . ! -name . -atime +1 -execdir rm -f -- {} \;
> # find . ! -name . -type d -mtime +1 -execdir rmdir -- {} \; \
> # >/dev/null 2>&1; }
> #fi
>
> Martin
>
>
