From: Sean Greenslade <sean@seangreenslade.com>
To: Marc Oggier <marc.oggier@megavolts.ch>, linux-btrfs@vger.kernel.org
Subject: Re: Spare Volume Features
Date: Wed, 28 Aug 2019 19:21:14 -0700 [thread overview]
Message-ID: <CD4A10E4-5342-4F72-862A-3A2C3877EC36@seangreenslade.com> (raw)
In-Reply-To: <0b7bfde0-0711-cee3-1ed8-a37b1a62bf5e@megavolts.ch>
On August 28, 2019 5:51:02 PM PDT, Marc Oggier <marc.oggier@megavolts.ch> wrote:
>Hi All,
>
>I am currently buidling a small data server for an experiment.
>
>I was wondering if the features of the spare volume introduced a couple
>
>of years ago (ttps://patchwork.kernel.org/patch/8687721/) would be
>release soon. I think this would be awesome to have a drive installed,
>that can be used as a spare if one drive of an array died to avoid
>downtime.
>
>Does anyone have news about it, and when it will be officially in the
>kernel/btrfs-progs ?
>
>Marc
>
>P.S. It took me a long time to switch to btrfs. I did it less than a
>year ago, and I love it. Keep the great job going, y'all
I've been thinking about this issue myself, and I have an (untested) idea for how to accomplish something similar. My file server has three disks in a btrfs raid1. I added a fourth disk to the array as just a normal, participating disk. I keep an eye on the usage to make sure that I never exceed 3 disk's worth of usage. That way, if one disk dies, there are still enough disks to mount RW (though I may still need to do an explicit degraded mount, not sure). In that scenario, I can just trigger an online full balance to rebuild the missing raid copies on the remaining disks. In theory, minimal to no downtime.
I'm curious if anyone can see any problems with this idea. I've never tested it, and my offsite backups are thorough enough to survive downtime anyway.
--Sean
next prev parent reply other threads:[~2019-08-29 2:31 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 [this message]
2019-08-29 22:41 ` waxhead
2019-09-01 3:28 ` Sean Greenslade
2019-09-01 8:03 ` Andrei Borzenkov
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=CD4A10E4-5342-4F72-862A-3A2C3877EC36@seangreenslade.com \
--to=sean@seangreenslade.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=marc.oggier@megavolts.ch \
/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).