On Mon, 2015-04-20 at 05:23 +0000, Duncan wrote: > Which, given the common developer wisdom about premature optimization, > can be explained. But accepting that explanation, one is still stymied > by the fact that all the previous warnings about btrfs being in heavy > development, keep good backups and be prepared to use them, etc, are > being stripped, because btrfs is supposedly ready for normal use now. > But if it's ready for normal use, why isn't it optimized for normal use, > then? And if it's not ready for normal use, why are the warnings > actually telling people that being prematurely stripped? Well I've mentioned it several times already, that the bad state of the documentation i.e. what can be expected (e.g. in terms of "Can I interrupt a fsck or will this be bad?" and so on), which functionalities are considered stable and which not, practical use cases and more in-depth (but still abstract, i.e. not at the developer/code level)... When should one use nodatacow, which implications does this have.
All these and much more missing documentations are currently one of the biggest obstacle in the way of using btrfs. And this kind of documentation need to be "definite" i.e. written by (main) developers and not "just" list regulars. Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
