From: Goffredo Baroncelli <kreijack@inwind.it>
To: Lennart Poettering <lennart@poettering.net>,
Harald Hoyer <harald@redhat.com>
Cc: linux-btrfs@vger.kernel.org, Kay Sievers <kay@vrfy.org>,
Chris Mason <clm@fb.com>, David Sterba <dsterba@suse.cz>
Subject: Re: Extend BTRFS_IOC_DEVICES_READY for degraded RAID
Date: Mon, 05 Jan 2015 17:36:34 +0100 [thread overview]
Message-ID: <54AABD92.9050904@inwind.it> (raw)
In-Reply-To: <20150105113147.GA18350@gardel-login>
On 2015-01-05 12:31, Lennart Poettering wrote:
> On Mon, 05.01.15 10:46, Harald Hoyer (harald@redhat.com) wrote:
>
>> We have BTRFS_IOC_DEVICES_READY to report, if all devices are present, so that
>> a udev rule can report ID_BTRFS_READY and SYSTEMD_READY.
>>
>> I think we need a third state here for a degraded RAID, which can be mounted,
>> but should only after a certain timeout/kernel command line params.
>>
>> We also have to rethink how to handle the udev DB update for the change of the
>> state. incomplete -> degraded -> complete
>
> I am not convinced that automatically booting degraded arrays would be
> a good idea. Instead, requiring one manual step before booting a
> degraded array sounds OK to me.
I think that a good use case is when the root filesystem is a raid one.
However I don't think that the current architecture is enough flexible to
perform this job:
- mounting a raid filesystem in degraded mode is good for some setup
but it is not the right solution for all: a configure
parameter to allow one behavior or the other is needed:
- the degraded mode should be allowed only if not all the devices are
discovered AND a timeout is expired. This timeout is another variable which
(IMHO) should be configurable;
- there are different degrees of degraded mode: if the raid is a RAID6,
losing a device would be acceptable; loosing two devices may be
unacceptable. Again there is no a simple answer; it is needed a
configurable policy;
- pay attention that the current architecture has some flaws: if a device
disappear during the device discovery, ID_BTRFS_READY returns OK
even if a device is missing.
I proposed a mount.btrfs helper[1], which (IMHO) is a good place for
this kind of job. However I have to point out that both Chris, and David
aren't fully convinced of this solution. I hope that they could change
opinion.
In conclusion, I see some use case to allow to mount a degraded btrfs
filesystem; however I don't see as viable the idea to enhance the
BTRFS_IOC_DEVICES_READY ioctl. More logic is required.
>
> Lennart
>
BR
G.Baroncelli
[1] http://www.spinics.net/lists/linux-btrfs/msg39706.html
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
next prev parent reply other threads:[~2015-01-05 16:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-05 9:46 Extend BTRFS_IOC_DEVICES_READY for degraded RAID Harald Hoyer
2015-01-05 11:31 ` Lennart Poettering
2015-01-05 12:08 ` Austin S Hemmelgarn
2015-01-05 16:36 ` Goffredo Baroncelli [this message]
2015-01-05 17:02 ` Austin S Hemmelgarn
2015-01-05 17:57 ` Goffredo Baroncelli
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=54AABD92.9050904@inwind.it \
--to=kreijack@inwind.it \
--cc=clm@fb.com \
--cc=dsterba@suse.cz \
--cc=harald@redhat.com \
--cc=kay@vrfy.org \
--cc=lennart@poettering.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.