All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Borisov <nborisov@suse.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 1/2] btrfs-progs: fi show: Print missing device for a mounted file system
Date: Thu, 2 Sep 2021 13:59:55 +0300	[thread overview]
Message-ID: <4da2f41d-c1e0-1da9-e4c9-bfe87067a6af@suse.com> (raw)
In-Reply-To: <5030bc35-fdda-b297-94e4-d484f8aee444@gmx.com>



On 2.09.21 г. 13:46, Qu Wenruo wrote:
> 
> 
> On 2021/9/2 下午6:41, Nikolay Borisov wrote:
>>
>>
>> On 2.09.21 г. 13:27, Qu Wenruo wrote:
>>>
>>>
>>> On 2021/9/2 下午6:06, Nikolay Borisov wrote:
>>>> Currently when a device is missing for a mounted filesystem the output
>>>> that is produced is unhelpful:
>>>>
>>>> Label: none  uuid: 139ef309-021f-4b98-a3a8-ce230a83b1e2
>>>>      Total devices 2 FS bytes used 128.00KiB
>>>>      devid    1 size 5.00GiB used 1.26GiB path /dev/loop0
>>>>      *** Some devices missing
>>>>
>>>> While the context which prints this is perfectly capable of showing
>>>> which device exactly is missing, like so:
>>>>
>>>> Label: none  uuid: 4a85a40b-9b79-4bde-8e52-c65a550a176b
>>>>      Total devices 2 FS bytes used 128.00KiB
>>>>      devid    1 size 5.00GiB used 1.26GiB path /dev/loop0
>>>>      devid    2 size 0 used 0 path /dev/loop1 ***MISSING***
>>>>
>>>> This is a lot more usable output as it presents the user with the id
>>>> of the missing device and its path.
>>>
>>> The idea is pretty awesome.
>>>
>>> Just one question, if one device is missing, how could we know its path?
>>> Thus does the device path output make any sense?
>>
>> The path is not canonicalized but otherwise the paths comes from
>> btrfs_ioctl_dev_info_args which is filled by a call to get_fs_info where
>> we call get_device_info for every device in the fs_info.
>>
>> So the path is really dev->name from kernel space or if we don't have a
>> dev->name it will be 0. In either case it's useful that we get the devid
>> so that the user can do :
>>
>> btrfs device remove 2 (if we take the above example), alternatively the
>> path would be a NULL-terminated string which aka empty. I guess that's
>> still better than simply saying *some devices are missing*
> 
> Definitely the devid output is way better than the existing output.
> 
> I just wonder can we skip the path completely since it's missing (and
> under most case its NULL anyway).
> 
> Despite that, I'm completely fine with the patch.

As you can see form the test I have added this was tested rather
synthetically by simply moving a loop device, in this case the device's
record was still in the fs_devices and had the name, though the name
itself couldn't be acted on. So omitting the path entirely is definitely
something we could do, but I'd rather try and be a bit cleverer, simply
checking if the name is null or not and if not just print it?

> 
> Thanks,
> Qu
> 
>>
>>>
>>> Thanks,
>>> Qu
>>>>
>>>> Signed-off-by: Nikolay Borisov <nborisov@suse.com>
>>>> ---
>>>>    cmds/filesystem.c | 7 +++----
>>>>    1 file changed, 3 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/cmds/filesystem.c b/cmds/filesystem.c
>>>> index db8433ba3542..ff13de6ac990 100644
>>>> --- a/cmds/filesystem.c
>>>> +++ b/cmds/filesystem.c
>>>> @@ -295,7 +295,6 @@ static int print_one_fs(struct
>>>> btrfs_ioctl_fs_info_args *fs_info,
>>>>    {
>>>>        int i;
>>>>        int fd;
>>>> -    int missing = 0;
>>>>        char uuidbuf[BTRFS_UUID_UNPARSED_SIZE];
>>>>        struct btrfs_ioctl_dev_info_args *tmp_dev_info;
>>>>        int ret;
>>>> @@ -325,8 +324,10 @@ static int print_one_fs(struct
>>>> btrfs_ioctl_fs_info_args *fs_info,
>>>>            /* Add check for missing devices even mounted */
>>>>            fd = open((char *)tmp_dev_info->path, O_RDONLY);
>>>>            if (fd < 0) {
>>>> -            missing = 1;
>>>> +            printf("\tdevid %4llu size 0 used 0 path %s
>>>> ***MISSING***\n",
>>>> +                    tmp_dev_info->devid,tmp_dev_info->path);
>>>>                continue;
>>>> +
>>>>            }
>>>>            close(fd);
>>>>            canonical_path = path_canonicalize((char
>>>> *)tmp_dev_info->path);
>>>> @@ -339,8 +340,6 @@ static int print_one_fs(struct
>>>> btrfs_ioctl_fs_info_args *fs_info,
>>>>            free(canonical_path);
>>>>        }
>>>>
>>>> -    if (missing)
>>>> -        printf("\t*** Some devices missing\n");
>>>>        printf("\n");
>>>>        return 0;
>>>>    }
>>>>
>>>
> 

  reply	other threads:[~2021-09-02 10:59 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-02 10:06 [PATCH 1/2] btrfs-progs: fi show: Print missing device for a mounted file system Nikolay Borisov
2021-09-02 10:06 ` [PATCH 2/2] btrfs-progs: tests: Add test for fi show Nikolay Borisov
2021-09-02 10:27 ` [PATCH 1/2] btrfs-progs: fi show: Print missing device for a mounted file system Qu Wenruo
2021-09-02 10:41   ` Nikolay Borisov
2021-09-02 10:46     ` Qu Wenruo
2021-09-02 10:59       ` Nikolay Borisov [this message]
2021-09-02 12:17         ` Qu Wenruo
2021-09-06 16:47           ` g.btrfs
2021-09-06 23:24             ` Anand Jain
2021-09-07  6:03             ` Nikolay Borisov
2021-09-07  8:59               ` Graham Cobb
2021-09-07  9:15                 ` Nikolay Borisov
2021-09-07 16:28             ` Goffredo Baroncelli
2021-09-02 11:44 ` Anand Jain
2021-09-02 14:28   ` Nikolay Borisov
2021-09-03  5:12     ` Anand Jain
2021-09-03  6:58       ` Nikolay Borisov
2021-09-07 13:50 ` David Sterba
2021-09-07 14:18   ` Nikolay Borisov
2021-09-08 11:17   ` Nikolay Borisov
2022-03-29  8:30 Nikolay Borisov
2022-06-07  8:35 ` Nikolay Borisov
2022-07-18 15:59   ` David Sterba

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=4da2f41d-c1e0-1da9-e4c9-bfe87067a6af@suse.com \
    --to=nborisov@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.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 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.