From: Andrei Borzenkov <arvidjaar@gmail.com>
To: Sean Greenslade <sean@seangreenslade.com>, linux-btrfs@vger.kernel.org
Subject: Re: Spare Volume Features
Date: Sun, 1 Sep 2019 11:03:59 +0300 [thread overview]
Message-ID: <6590a3f4-891d-2b22-ed43-4d2def43f290@gmail.com> (raw)
In-Reply-To: <20190901032855.GA5604@coach>
01.09.2019 6:28, Sean Greenslade пишет:
>
> I decided to do a bit of experimentation to test this theory. The
> primary goal was to see if a filesystem could suffer a failed disk and
> have that disk removed and rebalanced among the remaining disks without
> the filesystem losing data or going read-only. Tested on kernel
> 5.2.5-arch1-1-ARCH, progs: v5.2.1.
>
> I was actually quite impressed. When I ripped one of the block devices
> out from under btrfs, the kernel started spewing tons of BTRFS errors,
> but seemed to keep on trucking. I didn't leave it in this state for too
> long, but I was reading, writing, and syncing the fs without issue.
> After performing a btrfs device delete <MISSING_DEVID>, the filesystem
> rebalanced and stopped reporting errors.
How many devices did filesystem have? What profiles did original
filesystem use and what profiles were present after deleting device?
Just to be sure there was no silent downgrade from raid1 to dup or
single as example.
> Looks like this may be a viable
> strategy for high-availability filesystems assuming you have adequate
> monitoring in place to catch the disk failures quickly. I personally
> wouldn't want to fully automate the disk deletion, but it's certainly
> possible.
>
This would be valid strategy if we could tell btrfs to reserve enough
spare space; but even this is not enough, every allocation btrfs does
must be done so that enough spare space remains to reconstruct every
other missing chunk.
Actually I now ask myself - what happens when btrfs sees unusable disk
sector(s) in some chunk? Will it automatically reconstruct content of
this chunk somewhere else? If not, what is an option besides full device
replacement?
next prev parent reply other threads:[~2019-09-01 8:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-29 0:51 Spare Volume Features Marc Oggier
2019-08-29 2:21 ` Sean Greenslade
2019-08-29 22:41 ` waxhead
2019-09-01 3:28 ` Sean Greenslade
2019-09-01 8:03 ` Andrei Borzenkov [this message]
2019-09-02 0:52 ` Sean Greenslade
2019-09-02 1:09 ` Chris Murphy
2019-09-03 11:35 ` Austin S. Hemmelgarn
2019-08-30 8:07 ` Anand Jain
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=6590a3f4-891d-2b22-ed43-4d2def43f290@gmail.com \
--to=arvidjaar@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=sean@seangreenslade.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).