linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: Qu Wenruo <quwenruo@cn.fujitsu.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 1/2] btrfs: Do per-chunk degrade mode check at mount time
Date: Thu, 17 Sep 2015 17:37:18 +0800	[thread overview]
Message-ID: <55FA89CE.4040005@oracle.com> (raw)
In-Reply-To: <55FA1BD5.7020400@cn.fujitsu.com>



Hi Qu,

On 09/17/2015 09:48 AM, Qu Wenruo wrote:
> To Anand Jain,
>
> Any feedback on this method to allow single chunk still be degraded
> mountable?
>
> It should be much better than allowing degraded mount for any missing
> device case.

yeah. this changes the way missing devices are counted and its more fine 
grained. makes sense to me.


> Thanks,
> Qu
>
> Qu Wenruo wrote on 2015/09/16 11:43 +0800:
>> Btrfs supports different raid profile for meta/data/sys, and as
>> different profile support different tolerated missing device, it's
>> better to check if it can be mounted degraded at a per-chunk base.
>>
>> So this patch will add check for read_one_chunk() against its profile,
>> other than checking it against with the lowest duplication profile.
>>
>> Reported-by: Zhao Lei <zhaolei@cn.fujitsu.com>
>> Reported-by: Anand Jain <anand.jain@oracle.com>
>> Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
>> ---
>>   fs/btrfs/volumes.c | 17 +++++++++++++++++
>>   1 file changed, 17 insertions(+)
>>
>> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
>> index 644e070..3272187 100644
>> --- a/fs/btrfs/volumes.c
>> +++ b/fs/btrfs/volumes.c
>> @@ -6164,12 +6164,15 @@ static int read_one_chunk(struct btrfs_root
>> *root, struct btrfs_key *key,
>>                 struct btrfs_chunk *chunk)
>>   {
>>       struct btrfs_mapping_tree *map_tree = &root->fs_info->mapping_tree;
>> +    struct super_block *sb = root->fs_info->sb;
>>       struct map_lookup *map;
>>       struct extent_map *em;
>>       u64 logical;
>>       u64 length;
>>       u64 devid;
>>       u8 uuid[BTRFS_UUID_SIZE];
>> +    int missing = 0;
>> +    int max_tolerated;
>>       int num_stripes;
>>       int ret;
>>       int i;
>> @@ -6238,7 +6241,21 @@ static int read_one_chunk(struct btrfs_root
>> *root, struct btrfs_key *key,
>>               btrfs_warn(root->fs_info, "devid %llu uuid %pU is missing",
>>                           devid, uuid);
>>           }
>> +        if (map->stripes[i].dev->missing)
>> +            missing++;
>>           map->stripes[i].dev->in_fs_metadata = 1;
>> +
>> +    }
>> +
>> +    /* XXX: Why the function name is SO LOOOOOOOOOOOOOOOOONG?! */
>> +    max_tolerated =
>> +        btrfs_get_num_tolerated_disk_barrier_failures(map->type);
>> +    if (missing > max_tolerated && !(sb->s_flags & MS_RDONLY)) {
>> +        free_extent_map(em);
>> +        btrfs_error(root->fs_info, -EIO,
>> +            "missing device(%d) exceeds the limit(%d), writeable
>> mount is not allowed\n",

  \n is not required.

Thanks, Anand

>> +            missing, max_tolerated);
>> +        return -EIO;
>>       }
>>
>>       write_lock(&map_tree->map_tree.lock);
>>

      reply	other threads:[~2015-09-17  9:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-16  3:43 [PATCH 1/2] btrfs: Do per-chunk degrade mode check at mount time Qu Wenruo
2015-09-16  3:43 ` [PATCH 2/2] btrfs: Remove unneeded missing device number check Qu Wenruo
2015-09-17  9:43   ` Anand Jain
2015-09-17 10:01     ` Qu Wenruo
2015-09-18  1:47       ` Anand Jain
2015-09-18  2:06         ` Qu Wenruo
2015-09-18  6:45           ` Anand Jain
2015-09-20  0:31             ` Qu Wenruo
2015-09-20  5:37               ` Anand Jain
2015-09-21  2:09                 ` Qu Wenruo
2015-09-17  1:48 ` [PATCH 1/2] btrfs: Do per-chunk degrade mode check at mount time Qu Wenruo
2015-09-17  9:37   ` Anand Jain [this message]

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=55FA89CE.4040005@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo@cn.fujitsu.com \
    /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).