Re: RFC: exporting info via sysfs [was Re: [patch 0/2] Control filesystem balances (kernel side)]
Hi, Goffredo, On Thu, Nov 04, 2010 at 11:55:24PM +0100, Goffredo Baroncelli wrote: I make a prototype for exporting info from btrfs via sysfs. Good stuff. I was going to take a look at doing that this weekend. :) Under /sys/btrfs were created two directories, named fs and devices. /sys/btrfs/fs/fs-uuid/ I'm pretty sure that /sys/btrfs won't get through any discussion on LKML. I'd suggest /sys/fs/btrfs as the base, since that's where the other filesystems seem to put their sysfs information. label- filesystem label num_devices- total number of devices open_devices - number of opened devices [...] /sys/btrfs/devices/dev-uuid/ devid - btrfs device number fsid - filesystem uuid (fs-uuid) major, minor - major minor I think the major, minor should instead be be a symlink to the relevant entry in /sys/devices/... (as done in /sys/block/*) or /sys/block (as done in /sys/block/md*/slaves). Call it device. name - device name Unnecessary -- and also, I think, unlikely to get through LKML review. Putting a device name here implies that the kernel knows better than userspace what the name of the device is (i.e. which device node you should be using). Having the link to /sys/block/* or /sys/devices/... as above is, I think, all that's needed here. Userspace should be able to convert the major/minor pair kept in /sys/fs/btrfs/devices/uuid/device/dev appropriately. writeable - is the device writeable where fs-uuid is the filesystem uuid, and dev-uuid is the device uuid. The link between devices and filesystem is the fsid parameter of a device. Could that be made a symlink instead? That seems to be the usual approach in sysfs. I create these structure because we should handle the case were the devices are present (like after a btrfs device scan) but the filesystem aren't mounted. ... ah, I see it can't. (Re: my previous comment) In this case the devices/ subdirectory is populated. Instead the fs/ subdirectory is empty. I don't attach a patch because the code is very ugly. Comments ? Thoughts ? Is it ugly because there are significant difficulties in making btrfs or sysfs do this, or just because you hacked something together as quickly as possible for a demo? Hugo. -- === Hugo Mills: h...@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- There's a Martian war machine outside -- they want to talk --- to you about a cure for the common cold. signature.asc Description: Digital signature
R: Re: RFC: exporting info via sysfs [was Re: [patch 0/2] Control filesystem balances (kernel side)]
Messaggio originale Da: hugo-l...@carfax.org.uk Data: 05/11/2010 13.41 A: Goffredo Baroncellikreij...@libero.it Cc: linux-btrfs@vger.kernel.org, Hugo Millshugo-l...@carfax.org.uk Ogg: Re: RFC: exporting info via sysfs [was Re: [patch 0/2] Control filesystem balances (kernel side)] Hi, Goffredo, On Thu, Nov 04, 2010 at 11:55:24PM +0100, Goffredo Baroncelli wrote: I make a prototype for exporting info from btrfs via sysfs. Good stuff. I was going to take a look at doing that this weekend. :) Under /sys/btrfs were created two directories, named fs and devices. /sys/btrfs/fs/fs-uuid/ I'm pretty sure that /sys/btrfs won't get through any discussion on LKML. I'd suggest /sys/fs/btrfs as the base, since that's where the other filesystems seem to put their sysfs information. Not enough cofee... The right path is /sys/fs/btrfs (see examples in my email) label - filesystem label num_devices- total number of devices open_devices - number of opened devices [...] /sys/btrfs/devices/dev-uuid/ devid - btrfs device number fsid - filesystem uuid (fs-uuid) major, minor - major minor I think the major, minor should instead be be a symlink to the relevant entry in /sys/devices/... (as done in /sys/block/*) or /sys/block (as done in /sys/block/md*/slaves). Call it device. name - device name Unnecessary -- and also, I think, unlikely to get through LKML review. Putting a device name here implies that the kernel knows better than userspace what the name of the device is (i.e. which device node you should be using). Having the link to /sys/block/* or /sys/devices/... as above is, I think, all that's needed here. Apparently btrfs opens the device only when the filesystem is mounted. So before mounting a filesystem only the device file path exists. After the mounting major/minor have meaning values. Userspace should be able to convert the major/minor pair kept in /sys/fs/btrfs/devices/uuid/device/dev appropriately. writeable - is the device writeable where fs-uuid is the filesystem uuid, and dev-uuid is the device uuid. The link between devices and filesystem is the fsid parameter of a device. Could that be made a symlink instead? That seems to be the usual approach in sysfs. I create these structure because we should handle the case were the devices are present (like after a btrfs device scan) but the filesystem aren't mounted. ... ah, I see it can't. (Re: my previous comment) In this case the devices/ subdirectory is populated. Instead the fs/ subdirectory is empty. I don't attach a patch because the code is very ugly. Comments ? Thoughts ? Is it ugly because there are significant difficulties in making btrfs or sysfs do this, or just because you hacked something together as quickly as possible for a demo? Both. Sysfs is not difficult to manage but there is a lot of redundant codes. Fortunately few #defines help a lot. In any case I have a lot of doubts about the locking... For this week I will try to sent the patches Hugo. -- === Hugo Mills: h...@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- There's a Martian war machine outside -- they want to talk --- to you about a cure for the common cold. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC: exporting info via sysfs [was Re: [patch 0/2] Control filesystem balances (kernel side)]
Hi all, I make a prototype for exporting info from btrfs via sysfs. Under /sys/btrfs were created two directories, named fs and devices. /sys/btrfs/fs/fs-uuid/ label - filesystem label num_devices- total number of devices open_devices - number of opened devices [...] /sys/btrfs/devices/dev-uuid/ devid - btrfs device number fsid - filesystem uuid (fs-uuid) major, minor - major minor name - device name writeable - is the device writeable where fs-uuid is the filesystem uuid, and dev-uuid is the device uuid. The link between devices and filesystem is the fsid parameter of a device. I create these structure because we should handle the case were the devices are present (like after a btrfs device scan) but the filesystem aren't mounted. In this case the devices/ subdirectory is populated. Instead the fs/ subdirectory is empty. I don't attach a patch because the code is very ugly. Comments ? Thoughts ? Below an example of use. $ /sbin/blkid img* img0.img: UUID=099ea4b7-96dd-41fc-91df-0d1ab0066e05 UUID_SUB=1103c4e9-2dba-4b58-82ea-7c7c633fe04a TYPE=btrfs img1.img: UUID=099ea4b7-96dd-41fc-91df-0d1ab0066e05 UUID_SUB=d677e338-5eb0-4373-a540-78b9e7938987 TYPE=btrfs img2.img: UUID=099ea4b7-96dd-41fc-91df-0d1ab0066e05 UUID_SUB=de5e3fbf-2400-438c-95b5-e4c876d96bed TYPE=btrfs img3.img: UUID=099ea4b7-96dd-41fc-91df-0d1ab0066e05 UUID_SUB=019b1657- edad-488e-ad72-ccd2ea92e3ac TYPE=btrfs $ (cd /sys/fs/btrfs/; for i in */*/*; do echo -e $i:\t$(cat $i); done ) devices/019b1657-edad-488e-ad72-ccd2ea92e3ac/devid: 4 devices/019b1657-edad-488e-ad72-ccd2ea92e3ac/fsid: 099ea4b7-96dd-41fc-91df-0d1ab0066e05 devices/019b1657-edad-488e-ad72-ccd2ea92e3ac/major: 98 devices/019b1657-edad-488e-ad72-ccd2ea92e3ac/minor: 64 devices/019b1657-edad-488e-ad72-ccd2ea92e3ac/name: /dev/ubde devices/019b1657-edad-488e-ad72-ccd2ea92e3ac/writeable: 1 devices/1103c4e9-2dba-4b58-82ea-7c7c633fe04a/devid: 1 devices/1103c4e9-2dba-4b58-82ea-7c7c633fe04a/fsid: 099ea4b7-96dd-41fc-91df-0d1ab0066e05 devices/1103c4e9-2dba-4b58-82ea-7c7c633fe04a/major: 98 devices/1103c4e9-2dba-4b58-82ea-7c7c633fe04a/minor: 16 devices/1103c4e9-2dba-4b58-82ea-7c7c633fe04a/name: /dev/ubdb devices/1103c4e9-2dba-4b58-82ea-7c7c633fe04a/writeable: 1 devices/d677e338-5eb0-4373-a540-78b9e7938987/devid: 2 devices/d677e338-5eb0-4373-a540-78b9e7938987/fsid: 099ea4b7-96dd-41fc-91df-0d1ab0066e05 devices/d677e338-5eb0-4373-a540-78b9e7938987/major: 98 devices/d677e338-5eb0-4373-a540-78b9e7938987/minor: 32 devices/d677e338-5eb0-4373-a540-78b9e7938987/name: /dev/ubdc devices/d677e338-5eb0-4373-a540-78b9e7938987/writeable: 1 devices/de5e3fbf-2400-438c-95b5-e4c876d96bed/devid: 3 devices/de5e3fbf-2400-438c-95b5-e4c876d96bed/fsid: 099ea4b7-96dd-41fc-91df-0d1ab0066e05 devices/de5e3fbf-2400-438c-95b5-e4c876d96bed/major: 98 devices/de5e3fbf-2400-438c-95b5-e4c876d96bed/minor: 48 devices/de5e3fbf-2400-438c-95b5-e4c876d96bed/name: /dev/ubdd devices/de5e3fbf-2400-438c-95b5-e4c876d96bed/writeable: 1 fs/099ea4b7-96dd-41fc-91df-0d1ab0066e05/blocks_used:32768 fs/099ea4b7-96dd-41fc-91df-0d1ab0066e05/blocksize: 4096 fs/099ea4b7-96dd-41fc-91df-0d1ab0066e05/label: fs/099ea4b7-96dd-41fc-91df-0d1ab0066e05/num_devices:4 fs/099ea4b7-96dd-41fc-91df-0d1ab0066e05/open_devices: 4 fs/099ea4b7-96dd-41fc-91df-0d1ab0066e05/rw_devices: 4 fs/099ea4b7-96dd-41fc-91df-0d1ab0066e05/total_blocks: 981120 fs/099ea4b7-96dd-41fc-91df-0d1ab0066e05/total_devices: 4 On Saturday, 30 October, 2010, you (Goffredo Baroncelli) wrote: On Saturday, 30 October, 2010, Hugo Mills wrote: These two patches give a degree of control over balance operations. The first makes it possible to get an idea of how much work remains to do, by tracking the number of block groups (chunks) that need to be moved/rewritten. The second patch allows a running balance operation to be cancelled when the current block group has been moved. One fundamental question, though -- is the progress monitor function best implemented as an ioctl, as I've done here, or should it be two or three sysfs files? I'm thinking of /proc/mdstat... Obviously, /proc/mdstat would never get into /sys, but exposing the expected and remaining values as files has an attractive simplicity to it. I like the idea that these info should be put under sysfs. Something like /sys/btrfs/filesystem-uuid/ balance - info on balancing devices - list of device (a directory of links or a file which contains
