On Wed, Nov 25, 2015 at 12:20:09AM +0100, Christoph Anton Mitterer wrote: > On Tue, 2015-11-24 at 21:55 +0000, Hugo Mills wrote: > > 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. > Well... it may work in 99% cases... but there could something slip > through, which isn't as easy the case in manpages, which also tend to > be less messy than the huge pile of wiki pages where similar/related > things are described on different pages. > > Imagine a case, a non-experienced user update the wiki saying that -- > repair should be used, he may not even doing it in bad faith, perhaps > he had success with it and now writes a recipe. > It may take a while until someone of the more experienced guys notices > that and corrects it.
You can get update notifications, with the diffs for each page, via RSS. (At least, I do, and I think David and a few others monitor it in the same way). The window of failure is fairly small, particularly in view of the number of such "dangerous" changes made. The total vulnerability is measured in hours per year... > But if ", in the meantime had some fs corruptions,... I may experience > already severe problems by following that suggestion... (and while I do > have many backups of all my data, others may not, and if their life's > data is concerned, they'd be screwed). > > So even if it takes you just a few hours to correct such rubbish, you > know that Murphy's law may still hit n people during that time ;-) > > > > 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). > Well I can write a list together of things which I think should be part > of some more general documentation (i.e. less documentation about > options of the tools)... questions a complete newcomer to btrfs may > have who needs however more than "just a filesystem". > > > > 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. > Yeah, that was clear... :-) > Maybe call the "parent" from send -p "base" or something like that... > IMHO that would fit more as the parent there is more like a > "fundament". Yes, that makes sense. > Anyway, it's still not as bad as the usage of "RAID1" ;-) > > > > because > > you can't rename a subvol across another subvol boundary. > That's not quite clear to me... I had subvols like that: > /top/root/below-root > /top/below-top > and was able to move that to: > /top/root/below-top > /top/below-root > > i.e. not just changing names but swapping as in: > mv /top/root/below-top /top/tmp > mv /top/below-root /top/root/below-root > mv /top/tmp /top/below-top > > with top, root, below-top and below-root all being the same subvols With a recent mv, it'll be doing doing reflink copies followed by delete for all of the contents, which makes it pretty efficient, but I think you'll find that the UUID of the subvols changes. (At least, I hope it does. If it doesn't, then my mental model of what the FS is doing is *really* screwed up). Hugo. > Thanks a lot for your explanations :) > > Chris. -- Hugo Mills | Never underestimate the bandwidth of a Volvo filled hugo@... carfax.org.uk | with backup tapes. http://carfax.org.uk/ | PGP: E2AB1DE4 |
signature.asc
Description: Digital signature
