From: Dmitrii Tcvetkov <demfloro@demfloro.ru>
To: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2 0/6] Chunk level degradable check
Date: Mon, 6 Mar 2017 21:49:16 +0300 [thread overview]
Message-ID: <20170306214916.23c6fd20@fire> (raw)
In-Reply-To: <20170306085855.11403-1-quwenruo@cn.fujitsu.com>
On Mon, 6 Mar 2017 16:58:49 +0800
Qu Wenruo <quwenruo@cn.fujitsu.com> wrote:
> Btrfs currently uses num_tolerated_disk_barrier_failures to do global
> check for tolerated missing device.
>
> Although the one-size-fit-all solution is quite safe, it's too strict
> if data and metadata has different duplication level.
>
> For example, if one use Single data and RAID1 metadata for 2 disks, it
> means any missing device will make the fs unable to be degraded
> mounted.
>
> But in fact, some times all single chunks may be in the existing
> device and in that case, we should allow it to be rw degraded mounted.
>
> Such case can be easily reproduced using the following script:
> # mkfs.btrfs -f -m raid1 -d sing /dev/sdb /dev/sdc
> # wipefs -f /dev/sdc
> # mount /dev/sdb -o degraded,rw
>
> If using btrfs-debug-tree to check /dev/sdb, one should find that the
> data chunk is only in sdb, so in fact it should allow degraded mount.
>
> This patchset will introduce a new per-chunk degradable check for
> btrfs, allow above case to succeed, and it's quite small anyway.
>
> And enhance kernel error message for missing device, at least kernel
> can know what's making mount failed, other than meaningless
> "failed to read system chunk/chunk tree -5".
Hello,
Tested the patchset for raid1 and raid10. Successfully allows
degraded mount with single chunks on the filesystems without one drive.
Feel free to add Tested-By: Dmitrii Tcvetkov <demfloro@demfloro.ru>
next prev parent reply other threads:[~2017-03-06 19:01 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-06 8:58 [PATCH v2 0/6] Chunk level degradable check Qu Wenruo
2017-03-06 8:58 ` [PATCH v2 1/6] btrfs: Introduce a function to check if all chunks a OK for degraded rw mount Qu Wenruo
2017-03-07 4:48 ` Anand Jain
2017-03-08 18:26 ` Anand Jain
2017-03-09 0:31 ` Qu Wenruo
2017-03-06 8:58 ` [PATCH v2 2/6] btrfs: Do chunk level rw degrade check at mount time Qu Wenruo
2017-03-06 8:58 ` [PATCH v2 3/6] btrfs: Do chunk level degradation check for remount Qu Wenruo
2017-03-06 8:58 ` [PATCH v2 4/6] btrfs: Allow barrier_all_devices to do chunk level device check Qu Wenruo
2017-03-07 4:48 ` Anand Jain
2017-03-07 5:36 ` Qu Wenruo
2017-03-07 6:55 ` Anand Jain
2017-03-07 7:08 ` Qu Wenruo
2017-03-07 8:07 ` Qu Wenruo
2017-03-06 8:58 ` [PATCH v2 5/6] btrfs: Cleanup num_tolerated_disk_barrier_failures Qu Wenruo
2017-03-06 8:58 ` [PATCH v2 6/6] btrfs: Enhance missing device kernel message Qu Wenruo
2017-03-07 4:47 ` Anand Jain
2017-03-06 18:49 ` Dmitrii Tcvetkov [this message]
2017-03-07 0:36 ` [PATCH v2 0/6] Chunk level degradable check Adam Borowski
2017-03-07 1:35 ` Qu Wenruo
2017-03-07 2:23 ` Adam Borowski
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=20170306214916.23c6fd20@fire \
--to=demfloro@demfloro.ru \
--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.