From: Jens Bauer <jens-lists@gpio.dk>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: How robust is BTRFS?
Date: Thu, 3 Dec 2020 20:13:16 +0100 [thread overview]
Message-ID: <20201203201316503558.f535264b@gpio.dk> (raw)
In-Reply-To: <f51b636b-0e5f-c3d9-916f-f8196dae4ef0@suse.com>
Hi Qu.
On Thu, 3 Dec 2020 18:59:35 +0800, Qu Wenruo wrote:
>> The BTRFS developers deserves some credit!
>>
>> My setup was several RAID-10 partitions.
>
> You should be proud for not using RAID5/6. :)
Yes, I did investigate the status before I decided which RAID type to use.
I prioritize high throughput and stability over space.
>> After correcting the problem, I got curious and listed the
>> statistics for each partition.
>> I had more than 100000 read/write errors PER DAY for 6 months.
>> That's around 18 million read/write-errors, caused by drives turning
>> on/off "randomly".
(I remember some of the 'more than 100000 per day' to be 119xxx, so it may easily have been more than 20 million errors).
>> AND ALL MY FILES WERE INTACT.
>>
>> This is on the border to being impossible.
>
> I would say, yeah, really impressive, even to a btrfs developer.
I actually expected it would be. ;)
There are still things I forgot to mention in my first post:
A few of the RAID-partitions were in RAID0 configuration and files there were also intact.
(Had it been any other RAID0, I'd have lost every file on those partitions, no doubt!)
-Another thing I forgot to mention is the total usage was around 1.5TB out of a total of 2TB, and verifying that my files were intact took days, as I did a byte-by-byte comparison.
The drives mainly store: More than 170 Web-sites, mail for 4 domains, a lot of video files on a NAS and archives containing source-code (like GCC) for local caching.
> Btrfs RAID10/RAID1 by design is really good, since it has the extra
> checksum to make everything under check, thus unlike regular RAID10
> which can only handle missing device once, it knows which data is
> incorrect and will then just retry the good copy, and recovery the bad one.
That's something I really sensed when I saw what my files survived. =)
> Which means, btrfs can even handle extreme cases like 4 devices raid10,
> and each disk disappear for a while, but never 2 disks disappear together.
I had the impression that it would be able to handle two disappearances at the same time, but not 3 - but if it's limited by the design, I won't argue - you know the inner workings better than I. ;)
> But in your case, you really put btrfs failover to limit.
Completely unintended, but now you know how to make an extreme test-setup: Just make sure the drives don't get enough current. ;)
> Anyway, feel great that btrfs really helped you.
My experience with BTRFS made me want to use it in every possible place I can.
I'm even thinking of doing silly things like iSCSI for Mac, hosting HFS+ images on a BTRFS (I'm convinced it would even speed up HFS+).
> Thanks,
> Qu
I'm really the one who need to thank you. ;)
-May everyone on this list have a wonderful Christmas. =)
Love
Jens
prev parent reply other threads:[~2020-12-03 19:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-03 2:53 How robust is BTRFS? Jens Bauer
2020-12-03 7:59 ` Martin Steigerwald
2020-12-03 8:55 ` Jens Bauer
2020-12-03 10:59 ` Qu Wenruo
2020-12-03 19:13 ` Jens Bauer [this message]
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=20201203201316503558.f535264b@gpio.dk \
--to=jens-lists@gpio.dk \
--cc=linux-btrfs@vger.kernel.org \
--cc=wqu@suse.com \
/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.