From: Hugo Mills <hugo-lkml@carfax.org.uk>
To: Goffredo Baroncelli <kreijack@libero.it>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [patch 0/2] Control filesystem balances (kernel side)
Date: Mon, 1 Nov 2010 13:05:58 +0000 [thread overview]
Message-ID: <20101101130558.GB4709@vlad.carfax.org.uk> (raw)
In-Reply-To: <201010301944.35962.kreijack@libero.it>
[-- 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 --]
next prev parent reply other threads:[~2010-11-01 13:05 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-30 0:07 [patch 0/2] Control filesystem balances (kernel side) Hugo Mills
2010-10-30 0:07 ` [patch 1/2] Balance progress monitoring Hugo Mills
2010-10-30 13:37 ` Hugo Mills
2010-10-30 13:39 ` [patch 1/2] Balance progress monitoring (updated) Hugo Mills
2010-11-01 8:06 ` liubo
2010-11-01 12:55 ` Hugo Mills
2010-11-02 0:51 ` liubo
2010-10-30 0:07 ` [patch 2/2] Cancel filesystem balance Hugo Mills
2010-10-30 17:44 ` [patch 0/2] Control filesystem balances (kernel side) Goffredo Baroncelli
2010-11-01 12:58 ` Xavier Nicollet
2010-11-01 12:52 ` Tomasz Torcz
2010-11-01 13:05 ` Hugo Mills [this message]
2010-11-04 22:55 ` RFC: exporting info via sysfs [was Re: [patch 0/2] Control filesystem balances (kernel side)] Goffredo Baroncelli
2010-11-05 12:41 ` Hugo Mills
2010-11-08 18:01 [patch 0/2] Control filesystem balances (kernel side) Mike Fedyk
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=20101101130558.GB4709@vlad.carfax.org.uk \
--to=hugo-lkml@carfax.org.uk \
--cc=kreijack@libero.it \
--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.