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. 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". 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 Thanks a lot for your explanations :) Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
