From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: Anand Jain <anand.jain@oracle.com>, <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH 3/5] btrfs: Do per-chunk degraded check for remount
Date: Fri, 25 Sep 2015 16:08:24 +0800 [thread overview]
Message-ID: <560500F8.9070105@cn.fujitsu.com> (raw)
In-Reply-To: <5604EF8B.5060503@oracle.com>
Anand Jain wrote on 2015/09/25 14:54 +0800:
>
>
> On 09/21/2015 10:10 AM, Qu Wenruo wrote:
>> Just the same for mount time check, use new btrfs_check_degraded() to do
>> per chunk check.
>>
>> Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
>> ---
>> fs/btrfs/super.c | 11 +++++++----
>> 1 file changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
>> index c389c13..720c044 100644
>> --- a/fs/btrfs/super.c
>> +++ b/fs/btrfs/super.c
>> @@ -1681,11 +1681,14 @@ static int btrfs_remount(struct super_block
>> *sb, int *flags, char *data)
>> goto restore;
>> }
>>
>> - if (fs_info->fs_devices->missing_devices >
>> - fs_info->num_tolerated_disk_barrier_failures &&
>> - !(*flags & MS_RDONLY)) {
>> + ret = btrfs_check_degradable(fs_info, *flags);
>> + if (ret < 0) {
>> + btrfs_error(fs_info, ret,
>> + "degraded writable remount failed");
>
> btrfs_erorr() which is an error handling routine, isn't appropriate
> here, mainly because as we are in the remount context, I am not sure if
> you meant to change the fs state to readonly (on error) in the remount
> context ? or Instead btrfs_err() which is an error reporting/logging
> would be appropriate.
>
> btrfs_erorr() and btrfs_err() are way different in action but very easy
> have an oversight and use the wrong one. the below patch changed it..
>
> Btrfs: consolidate btrfs_error() to btrfs_std_error()
>
> Thanks, Anand
Thanks for pointing this out.
I was quite unsure about using btrfs_info/warn/error.
In this case, I just wan't to output a dmesg info to let user know
exactly what caused the mount failed.
Original code output nothing but "failed to open chunk tree", which is
quite confusing for end user.
I was planning to use btrfs_info, but at least this is really an error
message, but only to info user the real cause.
Maybe btrfs_warn will be a better choice?
Thanks,
Qu
>
>
>> + goto restore;
>> + } else if (ret > 0 && !btrfs_test_opt(root, DEGRADED)) {
>> btrfs_warn(fs_info,
>> - "too many missing devices, writeable remount is not
>> allowed");
>> + "some device missing, but still degraded mountable,
>> please remount with -o degraded option");
>> ret = -EACCES;
>> goto restore;
>> }
>>
next prev parent reply other threads:[~2015-09-25 8:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-21 2:10 [PATCH 0/5] Btrfs: Per-chunk degradable check Qu Wenruo
2015-09-21 2:10 ` [PATCH 1/5] btrfs: Introduce a new function to check if all chunks a OK for degraded mount Qu Wenruo
2016-04-18 8:47 ` [PATCH] btrfs: fix btrfs_check_degradable() to free extent map Anand Jain
2015-09-21 2:10 ` [PATCH 2/5] btrfs: Do per-chunk check for mount time check Qu Wenruo
2015-09-25 7:05 ` Anand Jain
2015-09-21 2:10 ` [PATCH 3/5] btrfs: Do per-chunk degraded check for remount Qu Wenruo
2015-09-25 6:54 ` Anand Jain
2015-09-25 8:08 ` Qu Wenruo [this message]
2015-09-25 8:30 ` Anand Jain
2015-09-25 8:34 ` Qu Wenruo
2015-09-25 8:24 ` [PATCH 1/1] " Anand Jain
2015-09-21 2:10 ` [PATCH 4/5] btrfs: Allow barrier_all_devices to do per-chunk device check Qu Wenruo
2015-10-30 8:32 ` Anand Jain
2015-10-30 11:41 ` Qu Wenruo
2015-10-30 23:52 ` Anand Jain
2015-09-21 2:10 ` [PATCH 5/5] btrfs: Cleanup num_tolerated_disk_barrier_failures Qu Wenruo
2015-11-05 0:57 ` [PATCH 0/5] Btrfs: Per-chunk degradable check Qu Wenruo
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=560500F8.9070105@cn.fujitsu.com \
--to=quwenruo@cn.fujitsu.com \
--cc=anand.jain@oracle.com \
--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.