From: Hugo Mills <hugo-lkml@carfax.org.uk> To: Goffredo Baroncelli <kreijack@libero.it> Cc: linux-btrfs@vger.kernel.org, Hugo Mills <hugo-lkml@carfax.org.uk> 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: <20101105124144.GA8002@vlad.carfax.org.uk> (raw) In-Reply-To: <201011042355.25214.kreijack@libero.it> [-- 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. -- === 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 --- "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 --]
prev parent 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: 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=20101105124144.GA8002@vlad.carfax.org.uk \ --to=hugo-lkml@carfax.org.uk \ --cc=kreijack@libero.it \ --cc=linux-btrfs@vger.kernel.org \ --subject='Re: RFC: exporting info via sysfs [was Re: [patch 0/2] Control filesystem balances (kernel side)]' \ /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
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.