On Sat, 2016-06-04 at 00:22 +0200, Brendan Hide wrote: > - 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. > I'm not certain why that patch didn't get any replies, though it > should also be noted that it was sent to three mailing lists - and > that btrfs was simply an implementation example. See previous thread > here: http://thread.gmane.org/gmane.linux.kernel/1622485 Ah... I remembered that one, but just couldn't find it anymore... so even two efforts already, both seem dead :-( > I recall reading it and thinking 6 parities is madness - but I > certainly see how it would be good for future-proofing. Well I can imagine that scenarios exist in which more than two parities may be highly desirable... > > - 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). > True also. There are various features and situations where btrfs > does not work as intelligently as expected. And even worse: Some of these are totally impossible to know for the average user. => the documentation issue (though at least the defrag issue is documented now in btrfs-filesystem(8) at least). > I class these under the "you're doing it wrong" theme. The vast > majority of popular database engines have been designed without CoW > in mind and, unfortunately, one *cannot* simply dump it onto a CoW > system and expect it to perform well. There is no easy answer here. Well the easy answer is: nodatacow At least in terms of: it's technically possible, not talking about "is it easy for the end-user (the average admin may possible at one point read that nodatacow should be done for VMs and DBs, but what about all the smallish DBs like Firefox sqlites and so on, or simply any other scenario where such IO patterns happen). But the problem with nodatacow is the implication of checksumming loss. > > - other earlier anticipated features like newer/better compression > > or > > checksum algos seem to be dead either > Re alternative compression: https://btrfs.wiki.kernel.org/index.php/ > FAQ#Will_btrfs_support_LZ4.3F > My short version: This is a premature optimisation. > > IMO, alternative checksums is also a premature optimisation. An RFC > for alternative checksums was last looked at by Liu Bo in November > 2014. A different strategy was proposed as the code didn't make use > of a pre-existing crypto code in the kernel. > > - still no real RAID 1 > This depends on what you mean by "real" - and I'm guessing you're > misled by mdraid's feature to have multiple copies in RAID1 rather > than just the two. RAID1 by definition is exactly two mirrored > copies. No more. No less. See my answer to Austin about the same claim. Actually I have no idea where it comes from,... even the more down-to- earth sources like Wikipedia all speak about "mirroring of all disks", as the original paper about RAID. > > - 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 > Simple answer: RAID5/6 is not yet recommended for storing data you > don't mind losing. Btrfs is *also* not yet ready for install-and- > forget-style system administration. Well the problem with writing good documentation in the "we do it once it's finished style" is often that it will never happen... or that the devs themselves don't recall all details. Also in the meantime there is so much (also often outdated) 3rd party documentation and myths that come alive, that it takes ages to clean up with all that. > I personally recommend against using btrfs for people who aren't > familiar with it. I think it *is* pretty important that many people try/test/play with it, because that helps stabilisation... but even during that phase, documentation would be quite important. If there would be e.g. an kept-up-to-date wiki page about the status and current perils of e.g. RAID5/6, people (like me) wouldn't ask every weeks, saving the devs' time. Plus people wouldn't end up simply trying it, believing it works already, and then face data loss. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
