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.
> > 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. 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) > 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) :-( > 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. > 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... So I guess whatever setup one uses nested/flat/mixed... doesn't rule out any functionalities for the future?! thx, Chris.
smime.p7s
Description: S/MIME cryptographic signature
