On Wed, Feb 12, 2014 at 05:01:23PM +0100, David Sterba wrote: > On Fri, Feb 07, 2014 at 10:20:10AM +0000, Hugo Mills wrote: > > On Fri, Feb 07, 2014 at 06:08:56PM +0800, Anand Jain wrote: > > > mainly here sysfs way defeats the purpose - debug as > > > mentioned. Sysfs would/should show only mounted disks, > > > > So let's find a way of showing the "known-about" data structure > > separately from the "mounted" data structure. Just thinking aloud > > here, how about something like this: > > > > For unmounted, but known filesystems: > > /sys/fs/btrfs/devmap/<UUID>/<symlink to device> (for each device known) > > /sys/fs/btrfs/devmap/<UUID>/label > > /sys/fs/btrfs/devmap/<UUID>/complete (0 if missing devices, 1 otherwise) > > /sys/fs/btrfs/devmap/<UUID>/<other properties> > > I like that, the device map represents the global state maintained by the > module, does not interfere with the current sysfs structure. > > One minor comment, the symlink to device should have probably a fixed > name so it can be easily located. Two ways spring to mind: Number them according to the internal FS's device numbers, so you'll have something like: $ ls -l /sys/fs/btrfs/devmap/3993e50e-a926-48a4-867f-36b53d924c35 total 0 lrwxrwxrwx 1 root root 0 Feb 1 11:22 0 -> ../../../../devices/pci0000:00/0000:00:04.0/0000:02:00.0/ata1/host0/target0:0:0/0:0:0:0/block/sda lrwxrwxrwx 1 root root 0 Feb 1 11:22 1 -> ../../../../devices/pci0000:00/0000:00:04.0/0000:02:00.0/ata1/host0/target0:1:0/0:1:0:0/block/sdb lrwxrwxrwx 1 root root 0 Feb 1 11:22 2 -> ../../../../devices/pci0000:00/0000:00:04.0/0000:02:00.0/ata1/host0/target0:2:0/0:2:0:0/block/sdc lrwxrwxrwx 1 root root 0 Feb 1 11:22 3 -> ../../../../devices/pci0000:00/0000:00:04.0/0000:02:00.0/ata1/host0/target0:3:0/0:3:0:0/block/sdd -r--r--r-- 1 root root 4096 Feb 1 11:22 complete -r--r--r-- 1 root root 4096 Feb 1 11:22 label Then you can find them easily by enumerating the filenames, and anything which is composed entirely of digits [0-9] is a device. Alternatively, put them into a subdirectory, and anything at all within that subdir is a device symlink. [snip] > > > the ioctl way doesn't have such a limitation (of course > > > as I commented memory dump way would have been best choice > > > but I got stuck with that approach if anybody wants to give > > > a try with that approach you are most welcome). > > > > > > IMO no harm to have both sysfs way and ioctl way let user > > > or developer use which were is suitable in their context. > > > > Extra maintenance overhead; divergence of the APIs. "You can find > > out the label of the filesystem using sysfs, but not the ioctl. You > > can find out the size of the filesystem using the ioctl, but not using > > sysfs." That way lies quite a bit of pain for the user of the > > interfaces. > > I won't mind having several ways how to get the information, sysfs, > ioctl or the properties. Each way has it's own pros and cons or is > suitable for some type of user (C program, shell scripts). Fair enough. I do worry a little about the API divergence, though. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- "What's so bad about being drunk?" "You ask a glass of water" ---
Attachment:
signature.asc
Description: Digital signature
