From: Goffredo Baroncelli <kreijack@inwind.it>
To: Jeff Mahoney <jeffm@suse.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [patch 00/13] sysfs publishing patchset
Date: Tue, 29 Oct 2013 22:57:29 +0100 [thread overview]
Message-ID: <52702F49.5060306@inwind.it> (raw)
In-Reply-To: <527019EF.5040608@suse.com>
Hi Jeff
On 2013-10-29 21:26, Jeff Mahoney wrote:
>> This for two reasons:
>> > 1) so it would be possible to show also the disks informations under a
>> > dev/ directory. It would be possible to handle the case that some disks
>> > are registered in btrfs but the related filesystems aren't mounted (like
>> > after a "btrfs dev scan" command)
>> >
>> > 2) it would help the browsing of the /sys/btrfs/ hierarchy: every
>> > directory under /sys/btrfs/fs/ represents a filesystem. With the current
>> > structure not all the directory under /sys/btrfs are related to a
>> > filesystem (like the features/ one, but I am sure that other directories
>> > sooner or later will appear)
> I'd like to define /sys/fs/btrfs/<fsid> as filesystem-specific and
> anything else as btrfs-wide.
I fully agree. My idea was to put under btrfs/dev *only* the device
which are registered in BTRFS by "btrfs dev scan" and/or mount commands.
> This is what ext4 already does with the
> exception that they use block device names instead of fsids. Your device
> use case is interesting, but a tough one to implement well since it is a
> cache that can be wrong as soon as the user decides to mkfs a device
> (either as btrfs or anything else) without calling btrfs dev scan
> afterward.
Right, I never though about this case.
> I wouldn't necessarily oppose such a feature; I just don't
> think it merits moving the primary case of per-filesystem information
> deeper into the hierarchy.
Fortunately the two thing are unrelated. The
/sys/fs/btrfs/dev/<device-uuid>/... hierarchy can live with
/sys/fs/btrfs/<fsid>/... or /sys/fs/btrfs/fs/<fsid>.
BTW, I am playing with your patch. What is the means of the field
<fsid>/allocation/*/disk_total ? In a RAID5 it seems to be the space
available ( == (<number-of-disk> - 1)*<size-of-chunk> ) and not the disk
space consumed ( == <number-of-disk> * <size-of-chunk> ). In fact it
seems that disk_total == total_bytes...
Ok looking at the kernel code (update_space_info() in extent-tree.c) it
seems that the info contained in space_info is bogus in case of
RAID5/RAID6....
--
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
prev parent reply other threads:[~2013-10-29 22:03 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-21 21:19 [patch 00/13] sysfs publishing patchset Jeff Mahoney
2013-10-21 21:19 ` [patch 01/13] btrfs: add ioctls to query/change feature bits online Jeff Mahoney
2013-10-21 21:19 ` [patch 02/13] kobject: export kobj_sysfs_ops Jeff Mahoney
2013-10-22 14:44 ` Jeff Mahoney
2013-10-21 21:19 ` [patch 03/13] btrfs: publish supported featured in sysfs Jeff Mahoney
2013-10-21 21:19 ` [patch 04/13] btrfs: publish per-super attributes " Jeff Mahoney
2013-10-21 21:19 ` [patch 05/13] btrfs: publish per-super features " Jeff Mahoney
2013-10-21 21:19 ` [patch 06/13] btrfs: publish unknown feature bits " Jeff Mahoney
2013-10-21 21:19 ` [patch 07/13] btrfs: add ability to change features via sysfs Jeff Mahoney
2013-10-21 21:19 ` [patch 08/13] btrfs: use feature attribute names to print better error messages Jeff Mahoney
2013-10-21 21:19 ` [patch 09/13] btrfs: add ioctl to export size of global metadata reservation Jeff Mahoney
2013-10-21 21:19 ` [patch 10/13] btrfs: publish allocation data in sysfs Jeff Mahoney
2013-10-29 18:49 ` Jeff Mahoney
2013-10-21 21:19 ` [patch 11/13] btrfs: publish device membership " Jeff Mahoney
2013-10-21 21:19 ` [patch 12/13] btrfs: publish fs label " Jeff Mahoney
2013-10-21 21:19 ` [patch 13/13] btrfs: add tracing for failed reservations Jeff Mahoney
2013-10-22 18:26 ` [patch 00/13] sysfs publishing patchset Josef Bacik
2013-10-22 18:39 ` Jeff Mahoney
2013-10-22 20:43 ` Josef Bacik
2013-10-29 18:25 ` Goffredo Baroncelli
2013-10-29 20:26 ` Jeff Mahoney
2013-10-29 21:57 ` Goffredo Baroncelli [this message]
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=52702F49.5060306@inwind.it \
--to=kreijack@inwind.it \
--cc=jeffm@suse.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 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.