All of
 help / color / mirror / Atom feed
From: Hugo Mills <>
To: Goffredo Baroncelli <>
Cc:, Hugo Mills <>
Subject: Re: RFC: exporting info via sysfs [was Re: [patch 0/2] Control filesystem balances (kernel side)]
Date: Fri, 5 Nov 2010 12:41:44 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 2880 bytes --]

   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 Mills: hugo@... | | ===
  PGP key: 515C238D from or
   --- "There's a Martian war machine outside -- they want to talk ---   
                to you about a cure for the common cold."                

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

      reply	other threads:[~2010-11-05 12:41 UTC|newest]

Thread overview: 14+ 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
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 [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \
    --subject='Re: RFC: exporting info via sysfs [was Re: [patch 0/2] Control filesystem balances (kernel side)]' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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.