From: Anand Jain <anand.jain@oracle.com>
To: linux-btrfs@vger.kernel.org
Cc: dsterba@suse.cz, clm@fb.com
Subject: [PATCH 0/2] [RFC] btrfs: create degraded-RAID1 chunks
Date: Thu, 28 Apr 2016 11:06:18 +0800 [thread overview]
Message-ID: <1461812780-538-1-git-send-email-anand.jain@oracle.com> (raw)
>From the comments that commit[1] deleted
- /*
- * we add in the count of missing devices because we want
- * to make sure that any RAID levels on a degraded FS
- * continue to be honored.
- *
appear to me that automatic reduced-chunk-allocation
when RAID1 is degraded wasn't in the original design.
which also introduced unpleasant things like automatically
allocating single chunks when RAID1 is mounted in degraded
mode, which will hinder further RAID1 mount in degraded
mode.
For example:
mkfs.btrfs -f -d raid1 -m raid1 /dev/sdc /dev/sdd
modprobe -r btrfs && modprobe btrfs
mount -o degraded /dev/sdc /btrfs
btrfs fi df /btrfs
Data, RAID1: total=409.56MiB, used=64.00KiB
Data, single: total=416.00MiB, used=128.00KiB
System, RAID1: total=8.00MiB, used=16.00KiB
System, single: total=32.00MiB, used=0.00B
Metadata, RAID1: total=409.56MiB, used=112.00KiB
Metadata, single: total=256.00MiB, used=0.00B
GlobalReserve, single: total=16.00MiB, used=0.00B
mount -o degraded /dev/sdc /btrfs <-- fails
So I am proposing to revert this commit [1].
And now to fix the original issue that is - chunk allocation
fails when RAID1 is degraded, The reason for the problem
seems to be that we had the devs_min attribute for RAID1
set wrongly. Correcting this also means that its time to
fix the RAID1 fixmes in the functions __btrfs_alloc_chunk()
patch [2] does that, and is for review.
Limited tested. For your review comments. Thanks.
[1]
------------------------------
commit 95669976bd7d30ae265db938ecb46a6b7f8cb893
Btrfs: don't consider the missing device when allocating new chunks
The original code allocated new chunks by the number of the writable
devices and missing devices to make sure that any RAID levels on a
degraded FS continue to be honored, but it introduced a problem that
it stopped us to allocating new chunks, the steps to reproduce is
following:
# mkfs.btrfs -m raid1 -d raid1 -f <dev0> <dev1>
# mkfs.btrfs -f <dev1> //Removing <dev1> from the original fs
# mount -o degraded <dev0> <mnt>
# dd if=/dev/null of=<mnt>/tmpfile bs=1M
It is because we allocate new chunks only on the writable devices,
if we take the number of missing devices into account, and want to
allocate new chunks with higher RAID level, we will fail because we
don't have enough writable device. Fix it by ignoring the number
of missing devices when allocating new chunks.
-----------------
[2]
[PATH] btrfs: create degraded-RAID1 chunks
Anand Jain (2):
btrfs: create degraded-RAID1 chunks
revert: Btrfs: don't consider the missing device when allocating new
chunks
fs/btrfs/extent-tree.c | 17 +++++++++++++++--
fs/btrfs/volumes.c | 38 +++++++++++++++++++++++++++++++++-----
2 files changed, 48 insertions(+), 7 deletions(-)
--
2.7.0
next reply other threads:[~2016-04-28 3:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-28 3:06 Anand Jain [this message]
2016-04-28 3:06 ` [PATCH 1/2] btrfs: create degraded-RAID1 chunks Anand Jain
2016-04-29 16:42 ` David Sterba
2016-05-02 6:10 ` Anand Jain
2016-05-10 11:00 ` Anand Jain
2016-04-28 3:06 ` [PATCH 2/2] revert: Btrfs: don't consider the missing device when allocating new chunks Anand Jain
2016-04-29 16:37 ` [PATCH 0/2] [RFC] btrfs: create degraded-RAID1 chunks David Sterba
2016-05-02 4:12 ` Anand Jain
2016-05-02 5:30 ` Duncan
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=1461812780-538-1-git-send-email-anand.jain@oracle.com \
--to=anand.jain@oracle.com \
--cc=clm@fb.com \
--cc=dsterba@suse.cz \
--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 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).