From: Anand Jain <anand.jain@oracle.com>
To: dsterba@suse.cz, Hugo Mills <hugo@carfax.org.uk>,
Goffredo Baroncelli <kreijack@libero.it>,
linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: introduce BTRFS_IOC_GET_DEVS
Date: Wed, 26 Feb 2014 10:34:58 +0800 [thread overview]
Message-ID: <530D52D2.7050808@oracle.com> (raw)
In-Reply-To: <20140225174523.GA16073@twin.jikos.cz>
On 26/02/2014 01:45, David Sterba wrote:
> On Wed, Feb 12, 2014 at 04:15:55PM +0000, Hugo Mills wrote:
>> On Wed, Feb 12, 2014 at 05:01:23PM +0100, David Sterba wrote:
>>> On Fri, Feb 07, 2014 at 10:20:10AM +0000, Hugo Mills wrote:
>>>> For unmounted, but known filesystems:
>>>> /sys/fs/btrfs/devmap/<UUID>/<symlink to device> (for each device known)
>>>> /sys/fs/btrfs/devmap/<UUID>/label
>>>> /sys/fs/btrfs/devmap/<UUID>/complete (0 if missing devices, 1 otherwise)
>>>> /sys/fs/btrfs/devmap/<UUID>/<other properties>
>>>
>>> I like that, the device map represents the global state maintained by the
>>> module, does not interfere with the current sysfs structure.
>>>
>>> One minor comment, the symlink to device should have probably a fixed
>>> name so it can be easily located.
>>
>> Two ways spring to mind: Number them according to the internal FS's
>> device numbers, so you'll have something like:
>>
>> $ ls -l /sys/fs/btrfs/devmap/3993e50e-a926-48a4-867f-36b53d924c35
>> total 0
>> lrwxrwxrwx 1 root root 0 Feb 1 11:22 0 -> ../../../../devices/pci0000:00/0000:00:04.0/0000:02:00.0/ata1/host0/target0:0:0/0:0:0:0/block/sda
>> lrwxrwxrwx 1 root root 0 Feb 1 11:22 1 -> ../../../../devices/pci0000:00/0000:00:04.0/0000:02:00.0/ata1/host0/target0:1:0/0:1:0:0/block/sdb
>> lrwxrwxrwx 1 root root 0 Feb 1 11:22 2 -> ../../../../devices/pci0000:00/0000:00:04.0/0000:02:00.0/ata1/host0/target0:2:0/0:2:0:0/block/sdc
>> lrwxrwxrwx 1 root root 0 Feb 1 11:22 3 -> ../../../../devices/pci0000:00/0000:00:04.0/0000:02:00.0/ata1/host0/target0:3:0/0:3:0:0/block/sdd
>> -r--r--r-- 1 root root 4096 Feb 1 11:22 complete
>> -r--r--r-- 1 root root 4096 Feb 1 11:22 label
>>
>> Then you can find them easily by enumerating the filenames, and
>> anything which is composed entirely of digits [0-9] is a device.
>> Alternatively, put them into a subdirectory, and anything at all
>> within that subdir is a device symlink.
>
> A separate subdirectory looks more user friendly, a simple subdir/*
> would get them all, regardless of the names. This is much simpler than
> writing a "[0-9] [0-9][0-9] ..." pattern to match digits-only filenames.
Its better to have a btrfs sysfs layout posted (and update)
at the wiki so that (I)/anybody-keen can attempt it (at a later
point). Just would like to highlight that sysfs is end user
visible, having tons-of-info /debug information would clutter.
It doesn't have to match all the contents of BTRFS_IOC_GET_DEVS
(For example BTRFS_IOC_GET_DEVS tells if bdev pointer is set,
I doubt if this has to go into sysfs, knowing this info is
just good for debugging).
>>>>> IMO no harm to have both sysfs way and ioctl way let user
>>>>> or developer use which were is suitable in their context.
>>>>
>>>> Extra maintenance overhead; divergence of the APIs. "You can find
>>>> out the label of the filesystem using sysfs, but not the ioctl. You
>>>> can find out the size of the filesystem using the ioctl, but not using
>>>> sysfs." That way lies quite a bit of pain for the user of the
>>>> interfaces.
>>>
>>> I won't mind having several ways how to get the information, sysfs,
>>> ioctl or the properties. Each way has it's own pros and cons or is
>>> suitable for some type of user (C program, shell scripts).
>>
>> Fair enough. I do worry a little about the API divergence, though.
>
> That's a valid point, given the number of data retrieved by the ioctl,
> (I'm looking at v2 of Anand's patch https://patchwork.kernel.org/patch/3708901/)
> this would need to make it extensible and backward compatible.
BTRFS_IOC_GET_DEVS wasn't in the btrfs-next so backward compatible
part should be ok to defer as of now .? In any case would make
a frame-work for backward compatible.
Thanks, Anand
next prev parent reply other threads:[~2014-02-26 2:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-27 8:52 [PATCH] dump device list as seen by the kernel Anand Jain
2014-01-27 8:52 ` [PATCH] btrfs: introduce BTRFS_IOC_GET_DEVS Anand Jain
2014-01-27 8:47 ` Hugo Mills
2014-01-27 9:08 ` Anand Jain
2014-02-06 19:49 ` David Sterba
2014-02-06 20:09 ` Goffredo Baroncelli
2014-02-06 22:05 ` David Sterba
2014-02-07 10:08 ` Anand Jain
2014-02-07 10:20 ` Hugo Mills
2014-02-12 16:01 ` David Sterba
2014-02-12 16:15 ` Hugo Mills
2014-02-25 17:45 ` David Sterba
2014-02-26 2:34 ` Anand Jain [this message]
2014-01-27 8:56 ` [PATCH] btrfs-progs: introduce btrfs-devlist 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=530D52D2.7050808@oracle.com \
--to=anand.jain@oracle.com \
--cc=dsterba@suse.cz \
--cc=hugo@carfax.org.uk \
--cc=kreijack@libero.it \
--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;
as well as URLs for NNTP newsgroup(s).