From: waxhead <firstname.lastname@example.org> To: DanglingPointer <email@example.com>, firstname.lastname@example.org Subject: Re: RAID56 Warning on "multiple serious data-loss bugs" Date: Sat, 26 Jan 2019 13:07:41 +0100 Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> 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.
next prev parent reply index Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-01-26 11:45 DanglingPointer 2019-01-26 12:07 ` waxhead [this message] 2019-01-26 14:05 ` Remi Gauvin 2019-01-28 0:52 ` Qu Wenruo 2019-01-28 15:23 ` Supercilious Dude 2019-01-28 16:24 ` Adam Borowski 2019-01-28 22:07 ` DanglingPointer 2019-01-28 22:52 ` Remi Gauvin 2019-01-29 19:02 ` Chris Murphy 2019-01-29 19:47 ` Goffredo Baroncelli 2019-01-30 1:41 ` DanglingPointer 2019-02-01 18:45 ` Remi Gauvin 2019-01-29 1:46 ` Qu Wenruo
Reply instructions: You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-BTRFS Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-btrfs/0 linux-btrfs/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-btrfs linux-btrfs/ https://lore.kernel.org/linux-btrfs \ email@example.com firstname.lastname@example.org public-inbox-index linux-btrfs Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-btrfs AGPL code for this site: git clone https://public-inbox.org/ public-inbox