Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: dsterba@suse.cz
Cc: Josef Bacik <josef@toxicpanda.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2 2/2] btrfs: sysfs add devinfo/fsid to retrieve fsid from the device
Date: Thu, 2 Dec 2021 00:56:37 +0800	[thread overview]
Message-ID: <eff38ce9-8f93-34f6-2cc5-40c06d2a8894@oracle.com> (raw)
In-Reply-To: <5f269a90-7145-0991-5da4-5f03fc0937fa@oracle.com>


David,

  Gentle ping on this patch?

Thanks, Anand


On 17/11/2021 11:29, Anand Jain wrote:
> 
> 
> On 17/11/2021 01:16, David Sterba wrote:
>> On Thu, Oct 21, 2021 at 11:31:17PM +0800, Anand Jain wrote:
>>> In the case of the seed device, the fsid can be different from the 
>>> mounted
>>> sprout fsid.  The userland has to read the device superblock to know the
>>> fsid but, that idea fails if the device is missing. So add a sysfs
>>> interface devinfo/<devid>/fsid to show the fsid of the device.
>>>
>>> For example:
>>>   $ cd /sys/fs/btrfs/b10b02a5-f9de-4276-b9e8-2bfd09a578a8
>>>
>>>   $ cat devinfo/1/fsid
>>>   c44d771f-639d-4df3-99ec-5bc7ad2af93b
>>>   $ cat  devinfo/3/fsid
>>>   b10b02a5-f9de-4276-b9e8-2bfd09a578a8
>>
>>  From user perspective, it's another fsid, one is in the path, so I'm
>> wondering if it should be named like read_fsid or sprout_fsid or if the
>> seed/sprout information should be put into another directory completely.
> 
> I am viewing it as fsid as per the device's sb. This fsid matches with
> the blkid(8) output. A path to the device's fsid will help to script.
> So I am not voting for sprout_fsid because it does not exist in the
> most common non-sprouted fsid.
> 
> Now to show whether a device is seed or sprout, the user friendly
> approach will be like for example:
>       /sys/fs/btrfs/<fsid>/devinfo/<devid>/device_state
> to show all that apply, for example:
>       SEED|SPROUT|READ_ONLY|WRITABLE|ZONED|METADATA_ONLY|\
>       DATA_ONLY|READ_PREFERRED|REPLACE_TGT|REPLACE_SRC|\
>       SCRUB_RUNNING
> 
> However, per kernel general rule of thumb one value per sys-fs file,
> so it should be for example:
>       /sys/fs/btrfs/<fsid>/devinfo/<devid>/seed
> 0
>       /sys/fs/btrfs/<fsid>/devinfo/<devid>/sprout
> 1
> 
> So based on this my patch "btrfs: introduce new device-state
> read_preferred" in the mailing list already proposed
>       /sys/fs/btrfs/<fsid>/devinfo/<devid>/read_preferred
> 
> So to summarize,  I can rename fsid to read_fsid. And, progressively
> in a separate patch, we can add <>/seed <>/sprout sysfs files as above.
> What do you think?

  reply	other threads:[~2021-12-01 16:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-21 15:31 [PATCH v2 0/2] provide fsid in sysfs devinfo Anand Jain
2021-10-21 15:31 ` [PATCH v2 1/2] btrfs: sysfs convert scnprintf and snprintf to use sysfs_emit Anand Jain
2021-10-21 16:19   ` David Sterba
2021-10-21 16:25     ` David Sterba
2021-10-21 16:27       ` Anand Jain
2021-10-21 16:27     ` Anand Jain
2021-10-21 15:31 ` [PATCH v2 2/2] btrfs: sysfs add devinfo/fsid to retrieve fsid from the device Anand Jain
2021-11-16 17:16   ` David Sterba
2021-11-17  3:29     ` Anand Jain
2021-12-01 16:56       ` Anand Jain [this message]
2021-12-07 18:56       ` David Sterba
2021-12-07 18:56   ` David Sterba
2021-11-09 10:09 ` [PATCH v2 0/2] provide fsid in sysfs devinfo Anand Jain

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=eff38ce9-8f93-34f6-2cc5-40c06d2a8894@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=dsterba@suse.cz \
    --cc=josef@toxicpanda.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox