From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: "csum failed" that was not detected by scrub
Date: Fri, 2 May 2014 10:20:03 +0000 (UTC) [thread overview]
Message-ID: <pan$ba09e$4b80fc30$5f891c70$5774c32f@cox.net> (raw)
In-Reply-To: CAOwjQU4GP5PjdPZx8HPihS7GQOA74M+DexwMWoh1FOQP0tCTcw@mail.gmail.com
Jaap Pieroen posted on Fri, 02 May 2014 11:42:35 +0200 as excerpted:
> I completed a full scrub:
> root@nasbak:/home/jpieroen# btrfs scrub status /home/
> scrub status for 7ca5f38e-308f-43ab-b3ea-31b3bcd11a0d
> scrub started at Wed Apr 30 08:30:19 2014
> and finished after 144131 seconds
> total bytes scrubbed: 4.76TiB with 0 errors
>
> Then tried to remove a device:
> root@nasbak:/home/jpieroen# btrfs device delete /dev/sdb /home
>
> This triggered bug_on, with the following error in dmesg: csum failed
> ino 258 off 1395560448 csum 2284440321 expected csum 319628859
>
> How can there still be csum failures directly after a scrub?
Simple enough, really...
> root@nasbak:/home/jpieroen# btrfs fi df /home
> Data, RAID5: total=4.57TiB, used=4.55TiB
> System, RAID1: total=32.00MiB, used=352.00KiB
> Metadata, RAID1: total=7.00GiB, used=5.59GiB
To those that know the details, this tells the story.
Btrfs raid5/6 modes are not yet code-complete, and scrub is one of the
incomplete bits. btrfs scrub doesn't know how to deal with raid5/6
properly just yet.
While the operational bits of raid5/6 support are there, parity is
calculated and written, scrub, and recovery from a lost device, are not
yet code complete. Thus, it's effectively a slower, lower capacity raid0
without scrub support at this point, except that when the code is
complete, you'll get an automatic "free" upgrade to full raid5 or raid6,
because the operational bits have been working since they were
introduced, just the recovery and scrub bits were bad, making it
effectively a raid0 in reliability terms, lose one and you've lost them
all.
That's the big picture anyway. Marc Merlin recently did quite a bit of
raid5/6 testing and there's a page on the wiki now with what he found.
Additionally, I saw a scrub support for raid5/6 modes patch on the list
recently, but while it may be in integration, I believe it's too new to
have reached release yet.
Wiki, for memory or bookmark: https://btrfs.wiki.kernel.org
Direct user documentation link for bookmark (unwrap as necessary):
https://btrfs.wiki.kernel.org/index.php/
Main_Page#Guides_and_usage_information
The raid5/6 page (which I didn't otherwise see conveniently linked, I dug
it out of the recent changes list since I knew it was there from on-list
discussion):
https://btrfs.wiki.kernel.org/index.php/RAID56
@ Marc or Hugo or someone with a wiki account: Can this be more visibly
linked from the user-docs contents, added to the user docs category list,
and probably linked from at least the multiple devices and (for now) the
gotchas pages?
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2014-05-02 10:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-02 9:42 "csum failed" that was not detected by scrub Jaap Pieroen
2014-05-02 10:20 ` Duncan [this message]
2014-05-02 17:48 ` Jaap Pieroen
2014-05-03 3:10 ` btrfs raid56 Was: "csum failed" that was not detected by scrub Duncan
2014-05-03 7:53 ` btrfs raid56 Was: Jaap Pieroen
2014-05-03 13:31 ` Frank Holton
2014-05-03 13:57 ` "csum failed" that was not detected by scrub Marc MERLIN
2014-05-02 11:13 ` Shilong Wang
2014-05-02 17:55 ` Jaap Pieroen
Reply instructions:
You may reply publicly 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 \
--in-reply-to='pan$ba09e$4b80fc30$5f891c70$5774c32f@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.