diff options
author | Qu Wenruo <quwenruo@cn.fujitsu.com> | 2017-03-09 09:34:36 +0800 |
---|---|---|
committer | David Sterba <dsterba@suse.com> | 2017-08-16 16:12:02 +0200 |
commit | 21634a19f6467674ef67fba9714c835a1c0a1e67 (patch) | |
tree | 4953bf1f28e56a0830f1ea7080e249ed9839124b /lib | |
parent | 0d1e0bead62a1778c45f22439cf067e63068faea (diff) | |
download | linux-21634a19f6467674ef67fba9714c835a1c0a1e67.tar.bz2 |
btrfs: Introduce a function to check if all chunks a OK for degraded rw mount
Introduce a new function, btrfs_check_rw_degradable(), to check if all
chunks in btrfs is OK for degraded rw mount.
It provides the new basis for accurate btrfs mount/remount and even
runtime degraded mount check other than old one-size-fit-all method.
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.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: David Sterba <dsterba@suse.com>
[ copied text from cover letter with more details about the problem being
solved ]
Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'lib')
0 files changed, 0 insertions, 0 deletions