From: Goffredo Baroncelli <kreijack@libero.it>
To: dsterba@suse.cz, Hugo Mills <hugo@carfax.org.uk>,
Anand Jain <anand.jain@oracle.com>,
linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: introduce BTRFS_IOC_GET_DEVS
Date: Thu, 06 Feb 2014 21:09:57 +0100 [thread overview]
Message-ID: <52F3EC15.1000508@libero.it> (raw)
In-Reply-To: <20140206194935.GT1364@twin.jikos.cz>
On 02/06/2014 08:49 PM, David Sterba wrote:
> On Mon, Jan 27, 2014 at 08:47:09AM +0000, Hugo Mills wrote:
>> On Mon, Jan 27, 2014 at 04:52:50PM +0800, Anand Jain wrote:
>>> The user land progs needs a simple way to read
>>> the raw list of disks and its parameters as
>>> btrfs kernel understands it. This patch will
>>> introduce BTRFS_IOC_GET_DEVS which dumps
>>> every thing under fs_devices.
>>>
>>> As of now btrfs-devlist uses this ioctl.
>>>
>>> In the long run this ioctl would help to optimize
>>> some part of btrfs-progs, mainly the current
>>> btrfs filesystem show
>>
>> Just thinking out loud here, really, but can we export this
>> information in /sys instead, rather than adding yet more ioctls?
>
> I tend to agree that this belongs to sysfs, it's more flexible in case
> we'll add more per-device stats, ie. one file that holds all the stats
> about the device. This is also easier to use from scripts that gather
> system information.
>
> With 3.14 the sysfs interface is available, but the devices under
> /sys/fs/btrfs/<fs-uuid>/devices/...
> are symlinks to the sysfs devices, so this btrfs-specific device
> information has to be located in a separate directory.
yes please; it would scale better than the ioctl()s; anyway I suggest 1
file per property, and not "...one file that holds all the stats
about the device"
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
next prev parent reply other threads:[~2014-02-06 20:10 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 [this message]
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
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=52F3EC15.1000508@libero.it \
--to=kreijack@libero.it \
--cc=anand.jain@oracle.com \
--cc=dsterba@suse.cz \
--cc=hugo@carfax.org.uk \
--cc=kreijack@inwind.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 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.