Re: [patch 0/2] Control filesystem balances (kernel side)
[ sorry for breaking the thread, I'm replying from the archives, I was unsubbed after a mail server issue and didn't notice till now... ] On Sat, Oct 30, 2010 at 07:44:35PM +0200, Goffredo Baroncelli wrote: balance- info on balancing Hugo Mills wrote: For the one-value-per-file rule of sysfs, this should probably be balance_expected and balance_completed, each holding a count of block groups. I'd name it balance_chunks_expected and balance_chunks_completed -- 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
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
Re: [patch 0/2] Control filesystem balances (kernel side)
Le 30 octobre 2010 à 19:44, Goffredo Baroncelli a écrit: 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 the list of devices) subvolumes/ - info on subvolume(s) label - label of the filesystem other btrfs filesystem related knoba Well, mdstat stats are under /proc/mdstat. Is sysfs the ideal place ? Just asking. -- Xavier Nicollet -- 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
Re: [patch 0/2] Control filesystem balances (kernel side)
On Mon, Nov 01, 2010 at 01:58:21PM +0100, Xavier Nicollet wrote: Le 30 octobre 2010 à 19:44, Goffredo Baroncelli a écrit: 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 the list of devices) subvolumes/ - info on subvolume(s) label - label of the filesystem other btrfs filesystem related knoba Well, mdstat stats are under /proc/mdstat. Is sysfs the ideal place ? mdstats are in sys: /sys/block/md127/md/ sync_action, sync_completed, sync_speed, reshape_position etc. /proc file is legacy. -- Tomasz Torcz Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes. -- Jim Gray -- 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
Re: [patch 0/2] Control filesystem balances (kernel side)
On Sat, Oct 30, 2010 at 07:44:35PM +0200, Goffredo Baroncelli wrote: On Saturday, 30 October, 2010, Hugo Mills wrote: 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/ /sys/fs/btrfs/uuid I think. Also: /sys/fs/btrfs/label as a symlink to the uuid directory. balance - info on balancing For the one-value-per-file rule of sysfs, this should probably be balance_expected and balance_completed, each holding a count of block groups. devices - list of device (a directory of links or a file which contains the list of devices) subvolumes/ - info on subvolume(s) label - label of the filesystem other btrfs filesystem related knoba The other one that struck me earlier today as being useful was tracking the progress of a dev delete operation. But that'll come later. Obviously we need another btrfs command to extract an uuid from a btrfs filesystem like: # btrfs filesystem get-uuid /path/to/a/btrfs/filesystem f9b9c413-0dc8-4e3f-94f2-86faa702f519 Possibly a slightly more general fi metadata with switches for UUID and label? # btrfs fi metadata [-u|--uuid] /path # btrfs fi metadata [-l|--label] /path 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 --- Is a diversity twice as good as a university? --- signature.asc Description: Digital signature
Re: [patch 0/2] Control filesystem balances (kernel side)
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 the list of devices) subvolumes/ - info on subvolume(s) label - label of the filesystem other btrfs filesystem related knoba Obviously we need another btrfs command to extract an uuid from a btrfs filesystem like: # btrfs filesystem get-uuid /path/to/a/btrfs/filesystem f9b9c413-0dc8-4e3f-94f2-86faa702f519 The user-space side of things are in a separate patch series, to follow. Please be gentle with me, this is my first (serious, non-trivial) kernel patch. :) 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 --- No! My collection of rare, incurable diseases! Violated! --- -- 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 -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreij...@inwind.it Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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
[patch 0/2] Control filesystem balances (kernel side)
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. The user-space side of things are in a separate patch series, to follow. Please be gentle with me, this is my first (serious, non-trivial) kernel patch. :) 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 --- No! My collection of rare, incurable diseases! Violated! --- -- 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
