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: hugo@... 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!" ---
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: hugo@... 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijack@inwind.it> Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
On Mon, Nov 01, 2010 at 01:58:21PM +0100, Xavier Nicollet wrote: > Le 30 octobre 2010 =C3=A0 19:44, Goffredo Baroncelli a =C3=A9crit: > > I like the idea that these info should be put under sysfs. Somethin= g like > >=20 > > /sys/btrfs/<filesystem-uuid>/ > > balance -> info on balancing > > devices -> list of device (a directory= of > > links or a file which co= ntains=20 > > the list of devices) > > subvolumes/ -> info on subvolume(s) > > label -> label of the filesystem > > <other btrfs filesystem related knoba> >=20 > 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. --=20 Tomasz Torcz "Never underestimate the bandwidth of a stat= ion xmpp: zdzichubg@chrome.pl wagon filled with backup tapes." -- Jim Gr= ay -- 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
Le 30 octobre 2010 =E0 19:44, Goffredo Baroncelli a =E9crit: > I like the idea that these info should be put under sysfs. Something = like >=20 > /sys/btrfs/<filesystem-uuid>/ > balance -> info on balancing > devices -> list of device (a directory o= f > links or a file which cont= ains=20 > 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. --=20 Xavier Nicollet -- 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
[-- Attachment #1: Type: text/plain, Size: 2060 bytes --] 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: hugo@... 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? --- [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 190 bytes --]
[ 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