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.
smime.p7s
Description: S/MIME cryptographic signature
