On Tue, Nov 24, 2015 at 10:25:50PM +0100, Christoph Anton Mitterer wrote: > On Tue, 2015-11-24 at 08:29 +0000, Duncan wrote: > > OK, found it on the wiki. It wasn't under use-cases, where I > > initially > > thought to look, but under sysadmin guide. Specifically, see section > > 4.2, managing snapshots, but I'd suggest reading the entire > > subvolumes > > discussion, section 4, or even most/all of the page. > > > > https://btrfs.wiki.kernel.org/index.php/SysadminGuide > Well I've had read that, but it's pretty vague and especially doesn't > mentioned any of the filesystem internal implications (if there are > any)... like I wondered before, whether this has effects on ref-links > not being used when e.g. sending/recieving ... or on future planned > extensions like recursive snapshots. No, there's no particular implications one way or the other in terms of reflinks. Obviously, if recursive snapshots get implemented, it'll remove some of the current awkwardness with nested subvols, but it won't invalidate any existing setups that use the recommendations in the Sysadmin Guide. > > Suppose you only want to rollback /, because some update screwed you > > up, > > but not /home, which is fine. If /home is a nested subvolume, then > > you're now mounting the nested home subvolume from some other nesting > > tree entirely, > That's a bit unclear to me,... I thought when I make a snapshot, any > nested subvols wouldn't be snapshotted and thus be empty dirs. Correct. This is actually a use-case for nested subvols, and one which snapper uses -- the target for snapshots of /foo is /foo/.snapshots/$date, where /foo/.snapshots is a subvol in its own right. So, if you have a subdir which you won't want to include in snapshots of a subvol, make it a subvol itself. > So I'd have rather that if I would simply have no /home (if I didn't > move it to the rolled-back subvol manually) Yup, this is one of the main reasons for not nesting subvols. > > 5 > > > > > +-roots (dir not subvol, note the s, rootS, plural) > > > +-root (subvol, mountpoint /) > > > > +-boot/ (dir) > > > > +-root/ (dir) > > > > +-lib/ (dir) > > > > +-home/ (empty dir as mountpoint) > > > +-root-snapshot-2015.0301 (dated snapshot of root) > > > +-root-snapshot-2015.0601 (dated snapshot of root) > > > +-root-snapshot-2015.0901 (dated snapshot of root) > > +-homes (dir not subvol) > > > +-home (subvol, mountpoint /home) > > > +-home-snapshot-2015.0301 (dated snapshot of home) > > ... > That's more what I've had in mind... > Actually something like this: > 5 > | > +-root (=subvol) > | +-boot > | +-home (subvo=/home being mounted heron) > | +-lib > +-home (subvol, the current version) > +-snapshots (=dir) > +-root > | +-2015-01-14 (subvol, snapshot) > | +-2015-09-30 (subvol, snapshot) > +-home > +-2015-06-04 (subvol, snapshot) > +-2015-09-01 (subvol, snapshot) > > > And it once more points to the problem of the wiki... anyone can write > (I think even I) and it's totally unclear at the first glance how > "[non-]official" and outdated something may be. > Apart from the problem that many important questions (from the PoV of > an more advanced admin that doesn't just do mkfs.btrfs and then never > again thinks about it) :-( In practice, new content is checked by a number of people when it's put in, so the case of someone putting random poorly-thought-out crap in the wiki isn't particularly likely to happen. > > Meanwhile, if the intention for a subvolume is simply to exclude that > > subtree from snapshotting of the parent, as might be the case for > > example > that is in fact also use case.. so in practise I'll probably have a mix > of (a) and (b). > > > > if you have a VMs subvol, with the VM image files set NOCOW to avoid > > fragmentation, since snapshotting nocow files forces cow1 (a cow at > > the > > first write of that block, before returning to nocow, because a > > snapshot > > locks the existing extents in place for the snapshot, so initial > > writes > > to a block after a snapshot /can't be nocow or it'd change the > > snapshot > > too...) > Ah that's good to know how that works (or better said, that it works at > all)... I've already wondered myself several times what happens when I > snapshot NOCOW files, ... something that's I guess also missing from > the (missing ;-) ) btrfs-end-user overview and details documentation. Please feel free to add the things you'd like to see. As I said above, we do check the docs on the wiki as they're changed, so if you're wrong on some details, it won't be a major issue for very long. If you want to discuss details before you write something, start a conversation -- either on here, or on IRC (or even on the Talk pages of the wiki). > > OTOH, if there's a chance you might want to mount that subvolume in a > > roll-back scenario, under the snapshot you're rolling back to, then > > it > > makes sense to put it directly under ID 5 again, and mount it in any > > case. > Yes. > > > > Then there's the security angle to consider. With the (basically, > > possibly modified as I suggested) flat layout, mounting something > > doesn't > > automatically give people in-tree access to nested subvolumes > > (subject to > > normal file permissions, of course), like nested layout does. And > > with > > (possibly modified) flat layout, the whole subvolume tree doesn't > > need to > > be mounted all the time either, only when you're actually working > > with > > subvolumes. > Uhm, I don't get the big security advantage here... whether nested or > manually mounted to a subdir,... if the permissions are insecure I'll > have a problem... if they're secure, than not. > > Of course I use insecure permissions and don't mount the subvols then > I'd be safe in flat setup, but not in a nested setup...(where they > subvol is "auto-mounted")... > > But that seems pretty awkward. > > > > Mhh I think my main question turns out to be whether the different > layouts would have any technical (i.e. not administrative) effects... > like the aforementioned stuff of recursive snapshots (should such thing > ever come to life). > But at least from the userspace tools it seems that I can move subvols > arbitrarily and they adapt their parent IDs accordingly... Pretty much, yes. Note that the "parent" of send -p and of snapshots is not the same relationship as the "parent" (containing subvol) of the tree structure. This is an awkward nomenclature problem, and I'm not sure how to fix it. The first meaning is fixed between a subvol and its snapshot when the snapshot is created, and won't change, regardless of how the snapshots are renamed/moved. The second meaning... actually, that doesn't change either, because you can't rename a subvol across another subvol boundary. (I only just realised this, halfway through the explanation). They're still different things, though. :) > So I guess whatever setup one uses nested/flat/mixed... doesn't rule > out any functionalities for the future?! Correct, it doesn't. Hugo. -- Hugo Mills | Anyone who claims their cryptographic protocol is hugo@... carfax.org.uk | secure is either a genius or a fool. Given the http://carfax.org.uk/ | genius/fool ratio for our species, the odds aren't PGP: E2AB1DE4 | good. Bruce Schneier
Attachment:
signature.asc
Description: Digital signature
