DanglingPointer wrote:
Hi All,
For clarity for the masses, what are the "multiple serious data-loss
bugs" as mentioned in the btrfs wiki?
The bullet points on this page:
https://btrfs.wiki.kernel.org/index.php/RAID56
don't enumerate the bugs. Not even in a high level. If anything what
can be closest to a bug or issue or "resilience use-case missing" would
be the first point on that page.
"Parity may be inconsistent after a crash (the "write hole"). The
problem born when after "an unclean shutdown" a disk failure happens.
But these are *two* distinct failures. These together break the BTRFS
raid5 redundancy. If you run a scrub process after "an unclean shutdown"
(with no disk failure in between) those data which match their checksum
can still be read out while the mismatched data are lost forever."
So in a nutshell; "What are the multiple serious data-loss bugs?" If
there aren't any, perhaps updating the wiki should be considered for
something less the "dramatic" .
I would just like to add that according to the status page the only
missing piece from a implementation point of view is the write hole.
https://btrfs.wiki.kernel.org/index.php/Status#RAID56
What effect exactly the write hole might have on *data* is not pointed
out in detail, but I would imagine that for some it might be desirable
to run a btrfs filesystem with metadata in "RAID" 1/10 mode and data in
"RAID" 5/6.
As far as I can understand this would leave you in a position where your
filesystem structures are relatively safe as "RAID" 1/10 mode is
considered stable. e.g. you should not loose or corrupt your filesystem
in the event of a crash / brownout. On the other hand you might loose or
corrupt a file being written which may or may not be acceptable for
some. In any case a scrub should fix any inconsistencies.
My point being that such a configuration might be (just?) as safe as for
exampel mdraid 5/6 and in some cases perhaps even more thanks to
checksumming and the self-heal features of btrfs.
Unless I am totally off I think it would be wise to add the metadata
"RAID" 1/10 and data "RAID" 5/6 method to the wiki as a possible "no
worse than any other XYZ solution" if you need storage and don't have
that much metadata in your filesystem.
