Re: applications hang on a btrfs spanning two partitions

[Marc Joliet <marcec@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 4466 bytes --]

Am Dienstag, 15. Januar 2019, 09:33:40 CET schrieb Duncan:
> Marc Joliet posted on Mon, 14 Jan 2019 12:35:05 +0100 as excerpted:
> > Am Montag, 14. Januar 2019, 06:49:58 CET schrieb Duncan:
> > [...]
> > 
> >> Unless you have a known reason not to[1], running noatime with btrfs
> >> instead of the kernel-default relatime is strongly recommended,
> >> especially if you use btrfs snapshotting on the filesystem.
> > 
> > [...]
> > 
> > The one reason I decided to remove noatime from my systems' mount
> > options is because I use systemd-tmpfiles to clean up cache directories,
> > for which it is necessary to leave atime intact (since caches are often
> > Write Once Read Many).
> 
> Thanks for the reply.  I hadn't really thought of that use, but it makes
> sense...

Specifically, I mean ~/.cache/ (plus a separate entry for ~/.cache/
thumbnails/, since I want thumbnails to live longer):

% grep \^[\^#] .config/user-tmpfiles.d/*.conf
.config/user-tmpfiles.d/clean.conf:d %C/thumbnails - - - 730d -
.config/user-tmpfiles.d/subvolumes.conf:q %C 0700 - - 60d -
.config/user-tmpfiles.d/subvolumes.conf:q %h/tmp 0700 - - - -

I don't use qgroups now, but will probably in the future, hence the use of "q" 
instead of "v".  ~/tmp/ is just a scratch space that I don't want snapshotted.

I haven't bothered configuring /var/cache/, other than making it a subvolume 
so it's not a part of my snapshots (overriding the systemd default of creating 
it as a directory).  It appears to me that it's managed just fine by pre-
existing tmpfiles.d snippets and by the applications that use it cleaning up 
after themselves (except for portage, see below).

> FWIW systemd here too, but I suppose it depends on what's being cached
> and particularly on the expense of recreation of cached data.  I actually
> have many of my caches (user/browser caches, etc) on tmpfs and reboot
> several times a week, so much of the cached data is only trivially cached
> as it's trivial to recreate/redownload.

While that sort of tmpfs hackery is definitely cool, my system is, despite its 
age, fast enough for me that I don't want to bother with that (plus I like my 
8 GB of RAM to be used just for applications and whatever Linux decides to 
cache in RAM).  Also, modern SSDs live long enough that I'm not worried about 
wearing them out through my daily usage (which IIRC was a major reason for you 
to do things that way).

> OTOH, running gentoo, my ccache and binpkg cache are seriously CPU-cycle
> expensive to recreate, so you can bet those are _not_ tmpfs, but OTTH,
> they're not managed by systemd-tmpfiles either.  (Ccache manages its own
> cache and together with the source-tarballs cache and git-managed repo
> trees along with binpkgs, I have a dedicated packages btrfs containing
> all of them, so I eclean binpkgs and distfiles whenever the 24-gigs space
> (48-gig total, 24-gig each on pair-device btrfs raid1) gets too close to
> full, then btrfs balance with -dusage= to reclaim partial chunks to
> unallocated.)

For distfiles I just have a weekly systemd timer that runs "eclean-dist -d" (I 
stopped using the buildpkg feature, so no eclean-pkg), and have moved both 
$DISTDIR and $PKGDIR to their future default locations in /var/cache/.  (They 
used to reside on my desktops HDD RAID1 as distinct subvolumes, but I recently 
bought a larger SSD, so I set up the above and got rid of two fstab entries.)

> Anyway, if you're not regularly snapshotting, relatime is reasonably
> fine, 

Personally, I don't notice the difference between noatime and relatime in day-
to-day usage (perhaps I just don't snapshot often enough).

> tho I'd still keep the atime effects in mind and switch to noatime
> if you end up in a recovery situation that requires writable mounting.
> (Losing a device in btrfs raid1 and mounting writable in ordered to
> replace it and rebalance comes to mind as one example of a writable-mount
> recovery scenario where noatime until full replace/rebalance/scrub
> completion would prevent unnecessary writes until the raid1 is safely
> complete and scrub-verified again.)

That all makes sense.  I was going to argue that I can't imagine randomly 
reading files in a recovery situation, but eventually realized that "ls" would 
be enough to trigger a directory atime update.  So yeah, one should keep the 
above mind.

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]