Hey.. Hm... so the overall btrfs state seems to be still pretty worrying, doesn't it?
- RAID5/6 seems far from being stable or even usable,... not to talk about higher parity levels, whose earlier posted patches (e.g. http://thread.gmane.org/gmane.linux.kernel/1654735) seem to have been given up. - Serious show-stoppers and security deficiencies like the UUID collision corruptions/attacks that have been extensively discussed earlier, are still open - a number of important core features not fully working in many situations (e.g. the issues with defrag, not being ref-link aware,... an I vaguely remember similar things with compression). - OTOH, defrag seems to be viable for important use cases (VM images, DBs,... everything where large files are internally re-written randomly). Sure there is nodatacow, but with that one effectively completely looses one of the core features/promises of btrfs (integrity by checksumming)... and as I've showed in an earlier large discussion, none of the typical use cases for nodatacow has any high-level checksumming, and even if, it's not used per default, or doesn't give the same benefits at it would on the fs level, like using it for RAID recovery). - other earlier anticipated features like newer/better compression or checksum algos seem to be dead either - still no real RAID 1 - no end-user/admin grade maangement/analysis tools, that tell non- experts about the state/health of their fs, and whether things like balance etc.pp. are necessary - the still problematic documentation situation
smime.p7s
Description: S/MIME cryptographic signature
