Re: btrfs

[Christoph Anton Mitterer <calestyo@scientia.net>]

[-- Attachment #1: Type: text/plain, Size: 4591 bytes --]

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 #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5930 bytes --]