Re: subvols and parents - how?

[Christoph Anton Mitterer <calestyo@scientia.net>]

[-- Attachment #1: Type: text/plain, Size: 2773 bytes --]

On Wed, 2015-12-09 at 11:26 +0000, Duncan wrote:
> > Hmm good point... I think it would be great if you could add that
> > scenario somewhere to the documentation. :-)
> FWIW, I (personally, not sure if that "you" was singular or plural)
> am 
> much more comfortable on the lists than on wikis, which I tend to
> treat 
> much as I did printed encyclopedias back in the day -- as great 
> references, but read-only from my perspective.
Well you (since it was your idea and I'd consider you "senior" enough
to do it, at least more senior than myself ;) )... or any developer of
course ;)

I did that now, or better said I largely rewrote:
https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Subvolumes
which I think should rather be its own wiki article.

One of the devs/experts... please double check it and pick/drop what
you like/dislike.
Especially notice that I've changed what was in the wiki, namely
subvolid=0 would mount the toplevel subovl,... I changed that to 5.
Also I assumed the manpage would be correct and subvol= is always
relative to the top level subvol, thus subvol=/ should mount that.

What's still missing now, IMHO, is:
- the snapshots subchapter itself is not complete (especially ro vs. rw
snapshots)... and implications like not mounting snapshots noatime, and
write amplification effects
- a guide when one should make subvole (e.g. keeping things on the root
fs together, unless it's separate like /var/www is usually, but
/var/lib typically "corresponds" to a state of /etc and /usr.
- what I've asked in another mail,.. about subvols and mountopts.

That rework also contains your security idea... shamelessly not quoting
you there O:-)


Well, I hope me editing such central part of the wiki wasn't to
bold,... but if it was, then I guess Chris Mason placing me on the
pillory would be nearly as big of an honour as being insulted by Linus
;-)



> While the appropriate place would be on the wiki, where there's a
> page 
> for that (here, the request is likely to be lost to history, while on
> the 
> wiki it's in a nice list that both devs and other requesters can look
> at, 
> a year, five years, a decade... into the future), in this case...
I think I'm simply going to add it there, in another bold step... O:-)


> There's already a framework for it and a limited implementation, tho
> only 
> a small subset of possible options are yet available.  The UI
> exposure is 
> as btrfs property (see the btrfs-property manpage), with the
> properties, 
> in general, implemented as extented attributes.
Mhh,... I've only recently learned about that properties... well if
that's technically possible to cleanly solve it with XATTRS... fine for
me.


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5313 bytes --]