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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
