Re: [PATCH] btrfs: Fix no space bug caused by removing bg

[Duncan <1i5t5.duncan@cox.net>]

Austin S Hemmelgarn posted on Tue, 22 Sep 2015 13:32:58 -0400 as
excerpted:

>> Of course, you shouldn't be nesting subvolumes anyway. It makes
>> it much harder to manage them.
> 
> That depends though, I only ever do single nesting (ie, a subvolume in a
> subvolume), and I use it to exclude stuff from getting saved in
> snapshots

Good point.

Such snapshot-exclusion-via-subvolume-boundary is a frequently 
recommended use-case for nocow files, of course, to keep them from 
fragmenting due to snapshot-provoked cow1.

If there's no (other) reason to mount the subvolumes separately, either 
because they're primarily snapshot-exclusion subvolumes or for whatever 
other reason they aren't intended to be specifically mounted, but 
instead, simply used as ordinary subdirs for most purposes, then nesting 
really /does/ make sense, because relying on the normal subdir behavior, 
that does avoid the otherwise necessary separate mount.


Which, meanwhile, brings up a particular bone I have to pick with 
systemd's use of btrfs subvolumes in various cases, particularly in 
tmpfiles.d usage, as well.  Since IIRC systemd 219, various previously 
created directories, including the (virtual-) machines tree, are by 
default subvolume-creations, now, of course only if they don't already 
exist.

These subvolumes are explicitly nested at whatever location they happen 
to appear in the subtree, as tmpfiles.d simply creates them as subvolumes, 
with a fallback to the standard subdirs they were created as in earlier 
versions on filesystems other than btrfs.  Other than the standard mount 
processing, which involves admins specifically setting up the appropriate 
subvolumes and mounts for them ahead of time, there's no provision made 
for creating them in a standard subvolume location at root level, and 
mounting them at whatever tree location their final destination is, as is 
standard recommended practice for btrfs "upstream".

Tho personally, I just prefer that they stay as subdirs, since I don't 
have any particular need to and therefore don't want to complicate my 
btrfs use-case with subvolumes, when I already break my tree up into 
multiple independent btrfs /filesystems/ using standard partitioning, 
etc, specifically in ordered to avoid having so many data eggs in one 
filesystem basket, and thus avoid the risk of losing them all should the 
bottom of that single basket fall out with the filesystem going bad on 
me.  I know from hard learned experience with much-too-big-mdraid arrays 
how painful maintenance operations can be when they take hours or days, 
compared to the seconds (due to ssd) or minutes (were they on spinning 
rust) maintenance such as balance or scrub now takes me on each of my all 
well under hundred-gig separate btrfs, with the difference even more 
pronounced since most of the time there's only one or two filesystems I 
need to do maintenance on, instead of the whole tree.

So I use multiple small independent btrfs, and don't want or need 
subvolumes, which would only complicate my use-case.  Fortunately, I can 
avoid systemd creating those subvolumes even tho I'm on btrfs, the normal 
target for them, by simply already having the subdirs created... as 
subdirs.  Tho the initial 219 implementation bugged out on them 
(subvolume-create error because my root filesystem is deliberately left 
read-only by default, which propagated thru to a tmpfiles.d service 
failure), I filed a bug, and by 221 (IIRC) tmpfiles.d was working 
correctly, leaving my existing subdirs alone.

Unfortunately, now I have to worry about manual subdir creation to avoid 
the automated subvolume creation on a new install, or should I forget, 
worry about discovering and undoing the automated subvolume create.

Oh, well...

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