linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: applications hang on a btrfs spanning two partitions
Date: Tue, 15 Jan 2019 08:33:40 +0000 (UTC)	[thread overview]
Message-ID: <pan$cd3b7$50e825ef$b5f86324$c489b494@cox.net> (raw)
In-Reply-To: 2486006.dzvMEKkTBt@thetick

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...

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.

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.)

Anyway, if you're not regularly snapshotting, relatime is reasonably 
fine, 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.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


  reply	other threads:[~2019-01-15  8:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-08 19:38 applications hang on a btrfs spanning two partitions Florian Stecker
2019-01-09  6:24 ` Nikolay Borisov
2019-01-09  9:16   ` Florian Stecker
2019-01-09 10:03     ` Nikolay Borisov
2019-01-09 20:10       ` Florian Stecker
2019-01-12  2:12         ` Chris Murphy
2019-01-12 10:19           ` Florian Stecker
2019-01-14  5:49             ` Duncan
2019-01-14 11:35               ` Marc Joliet
2019-01-15  8:33                 ` Duncan [this message]
2019-01-15 22:40                   ` Marc Joliet
2019-01-17 11:15                     ` Duncan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='pan$cd3b7$50e825ef$b5f86324$c489b494@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).