From: Andrei Borzenkov <arvidjaar@gmail.com>
To: Qu Wenruo <quwenruo@cn.fujitsu.com>,
linux-btrfs@vger.kernel.org, anand.jain@oracle.com,
kilobyte@angband.pl, demfloro@demfloro.ru
Subject: Re: [PATCH v3 7/7] btrfs: Enhance missing device kernel message
Date: Wed, 8 Mar 2017 08:26:25 +0300 [thread overview]
Message-ID: <55e7ff1e-d06a-7963-b4f8-8f9c215347f2@gmail.com> (raw)
In-Reply-To: <20170308024124.16899-8-quwenruo@cn.fujitsu.com>
08.03.2017 05:41, Qu Wenruo пишет:
> For missing device, btrfs will just refuse to mount with almost
> meaningless kernel message like:
>
> BTRFS info (device vdb6): disk space caching is enabled
> BTRFS info (device vdb6): has skinny extents
> BTRFS error (device vdb6): failed to read the system array: -5
> BTRFS error (device vdb6): open_ctree failed
>
> This patch will add extra device missing output, making the result to:
>
> BTRFS info (device vdb6): disk space caching is enabled
> BTRFS info (device vdb6): has skinny extents
> BTRFS warning (device vdb6): devid 2 uuid 80470722-cad2-4b90-b7c3-fee294552f1b is missing
> BTRFS error (device vdb6): failed to read the system array: -5
Unfortunately it is still unclear that failure to mount is caused by
missing device. As you explained (and the whole reason of this patch
series) we still are able to mount even with missing device(s). It
should print error (not warning) telling that some extents are not
accessible due to missing device(s).
> BTRFS error (device vdb6): open_ctree failed
>
> Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
> Reviewed-by: Anand Jain <anand.jain@oracle.com>
> ---
> fs/btrfs/volumes.c | 24 +++++++++++++++++-------
> fs/btrfs/volumes.h | 2 ++
> 2 files changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index 765d213ac5ef..f2c878d5f714 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -6442,6 +6442,7 @@ static int read_one_chunk(struct btrfs_fs_info *fs_info, struct btrfs_key *key,
> if (!map->stripes[i].dev &&
> !btrfs_test_opt(fs_info, DEGRADED)) {
> free_extent_map(em);
> + btrfs_report_missing_device(fs_info, devid, uuid);
> return -EIO;
> }
> if (!map->stripes[i].dev) {
> @@ -6452,8 +6453,7 @@ static int read_one_chunk(struct btrfs_fs_info *fs_info, struct btrfs_key *key,
> free_extent_map(em);
> return -EIO;
> }
> - btrfs_warn(fs_info, "devid %llu uuid %pU is missing",
> - devid, uuid);
> + btrfs_report_missing_device(fs_info, devid, uuid);
> }
> map->stripes[i].dev->in_fs_metadata = 1;
> }
> @@ -6570,17 +6570,21 @@ static int read_one_dev(struct btrfs_fs_info *fs_info,
>
> device = btrfs_find_device(fs_info, devid, dev_uuid, fs_uuid);
> if (!device) {
> - if (!btrfs_test_opt(fs_info, DEGRADED))
> + if (!btrfs_test_opt(fs_info, DEGRADED)) {
> + btrfs_report_missing_device(fs_info, devid, dev_uuid);
> return -EIO;
> + }
>
> device = add_missing_dev(fs_devices, devid, dev_uuid);
> if (!device)
> return -ENOMEM;
> - btrfs_warn(fs_info, "devid %llu uuid %pU missing",
> - devid, dev_uuid);
> + btrfs_report_missing_device(fs_info, devid, dev_uuid);
> } else {
> - if (!device->bdev && !btrfs_test_opt(fs_info, DEGRADED))
> - return -EIO;
> + if (!device->bdev) {
> + btrfs_report_missing_device(fs_info, devid, dev_uuid);
> + if (!btrfs_test_opt(fs_info, DEGRADED))
> + return -EIO;
> + }
>
> if(!device->bdev && !device->missing) {
> /*
> @@ -6806,6 +6810,12 @@ static bool device_has_rw_degrade_error(struct extra_rw_degrade_errors *errors,
> return ret;
> }
>
> +void btrfs_report_missing_device(struct btrfs_fs_info *fs_info, u64 devid,
> + u8 *uuid)
> +{
> + btrfs_warn_rl(fs_info, "devid %llu uuid %pU is missing", devid, uuid);
> +}
> +
> /*
> * Check if all chunks in the fs is OK for read-write degraded mount
> *
> diff --git a/fs/btrfs/volumes.h b/fs/btrfs/volumes.h
> index 67d7474e42a3..1f6ab55640da 100644
> --- a/fs/btrfs/volumes.h
> +++ b/fs/btrfs/volumes.h
> @@ -573,4 +573,6 @@ void record_extra_rw_degrade_error(struct extra_rw_degrade_errors *errors,
>
> bool btrfs_check_rw_degradable(struct btrfs_fs_info *fs_info,
> struct extra_rw_degrade_errors *errors);
> +void btrfs_report_missing_device(struct btrfs_fs_info *fs_info, u64 devid,
> + u8 *uuid);
> #endif
>
next prev parent reply other threads:[~2017-03-08 6:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-08 2:41 [PATCH v3 0/7] Chunk level degradable check Qu Wenruo
2017-03-08 2:41 ` [PATCH v3 1/7] btrfs: Introduce a function to check if all chunks a OK for degraded rw mount Qu Wenruo
2017-03-08 2:41 ` [PATCH v3 2/7] btrfs: Do chunk level rw degrade check at mount time Qu Wenruo
2017-03-08 2:41 ` [PATCH v3 3/7] btrfs: Do chunk level degradation check for remount Qu Wenruo
2017-03-08 2:41 ` [PATCH v3 4/7] btrfs: Introduce extra_rw_degrade_errors parameter for btrfs_check_rw_degradable Qu Wenruo
2017-03-08 2:41 ` [PATCH v3 5/7] btrfs: Allow barrier_all_devices to do chunk level device check Qu Wenruo
2017-03-08 2:41 ` [PATCH v3 6/7] btrfs: Cleanup num_tolerated_disk_barrier_failures Qu Wenruo
2017-03-08 2:41 ` [PATCH v3 7/7] btrfs: Enhance missing device kernel message Qu Wenruo
2017-03-08 5:26 ` Andrei Borzenkov [this message]
2017-03-08 5:43 ` Qu Wenruo
2017-03-08 6:47 ` [PATCH v3 0/7] Chunk level degradable check Adam Borowski
2017-03-08 7:39 ` Qu Wenruo
2017-03-08 18:40 ` Anand Jain
2017-03-08 19:01 ` Anand Jain
2017-03-08 8:00 ` Dmitrii Tcvetkov
2017-03-08 12:25 ` Austin S. Hemmelgarn
2017-03-08 18:31 ` Anand Jain
2017-03-08 21:08 ` Goffredo Baroncelli
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=55e7ff1e-d06a-7963-b4f8-8f9c215347f2@gmail.com \
--to=arvidjaar@gmail.com \
--cc=anand.jain@oracle.com \
--cc=demfloro@demfloro.ru \
--cc=kilobyte@angband.pl \
--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).