linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


             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).