linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).