* Re: [patch 0/2] Control filesystem balances (kernel side)
@ 2010-11-08 18:01 Mike Fedyk
0 siblings, 0 replies; 6+ messages in thread
From: Mike Fedyk @ 2010-11-08 18:01 UTC (permalink / raw)
To: linux-btrfs
[ 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [patch 0/2] Control filesystem balances (kernel side)
@ 2010-10-30 0:07 Hugo Mills
2010-10-30 17:44 ` Goffredo Baroncelli
0 siblings, 1 reply; 6+ messages in thread
From: Hugo Mills @ 2010-10-30 0:07 UTC (permalink / raw)
To: linux-btrfs
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!" ---
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [patch 0/2] Control filesystem balances (kernel side)
2010-10-30 0:07 Hugo Mills
@ 2010-10-30 17:44 ` Goffredo Baroncelli
2010-11-01 12:58 ` Xavier Nicollet
2010-11-01 13:05 ` Hugo Mills
0 siblings, 2 replies; 6+ messages in thread
From: Goffredo Baroncelli @ 2010-10-30 17:44 UTC (permalink / raw)
To: linux-btrfs
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [patch 0/2] Control filesystem balances (kernel side)
2010-10-30 17:44 ` Goffredo Baroncelli
@ 2010-11-01 12:58 ` Xavier Nicollet
2010-11-01 12:52 ` Tomasz Torcz
2010-11-01 13:05 ` Hugo Mills
1 sibling, 1 reply; 6+ messages in thread
From: Xavier Nicollet @ 2010-11-01 12:58 UTC (permalink / raw)
To: Goffredo Baroncelli; +Cc: linux-btrfs
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [patch 0/2] Control filesystem balances (kernel side)
2010-11-01 12:58 ` Xavier Nicollet
@ 2010-11-01 12:52 ` Tomasz Torcz
0 siblings, 0 replies; 6+ messages in thread
From: Tomasz Torcz @ 2010-11-01 12:52 UTC (permalink / raw)
To: linux-btrfs
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [patch 0/2] Control filesystem balances (kernel side)
2010-10-30 17:44 ` Goffredo Baroncelli
2010-11-01 12:58 ` Xavier Nicollet
@ 2010-11-01 13:05 ` Hugo Mills
1 sibling, 0 replies; 6+ messages in thread
From: Hugo Mills @ 2010-11-01 13:05 UTC (permalink / raw)
To: Goffredo Baroncelli; +Cc: linux-btrfs
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-11-08 18:01 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-11-08 18:01 [patch 0/2] Control filesystem balances (kernel side) Mike Fedyk
-- strict thread matches above, loose matches on Subject: below --
2010-10-30 0:07 Hugo Mills
2010-10-30 17:44 ` Goffredo Baroncelli
2010-11-01 12:58 ` Xavier Nicollet
2010-11-01 12:52 ` Tomasz Torcz
2010-11-01 13:05 ` Hugo Mills
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).