Messages in this thread | | | Date | Thu, 22 Mar 2001 18:07:44 -0500 (EST) | From | Alexander Viro <> | Subject | [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt) |
| |
[cc'd to fsdevel, since trick described below may be of interest for other folks]
On Thu, 22 Mar 2001, Dave Kleikamp wrote:
> Alexander Viro wrote: > > > > On Thu, 22 Mar 2001, Dave Kleikamp wrote: > > > > > Linus, > > > I would like to reserve a block of 32 ioctl's for the JFS filesystem. > > > > Details, please? More specifically, what kind of objects are these ioctls > > applied to? > > I don't have all the details worked out yet, but the utilities to extend > and defragment the filesystem will operate on a live volume, so the > utilities will need to talk to the filesystem to move blocks, extend the > block map, etc. > > The utilities will probably open the root directory and apply the ioctls > to it, unless there is a better way to do it.
There is - and it may simplify your life, actually. Here's what can be done: a) Use _two_ DECLARE_FSTYPE in your filesystem. Say it, for JFS (normal) and jfsmeta. Make it FS_LITTER one. b) let jfsmeta_read_super() take a pathname as an option (say it, require "-o jfsroot=<some_path>") c) let it do lookup on that pathname and verify that it's on JFS error = 0; if (path_init(jfsroot, LOOKUP_FOLLOW|LOOKUP_POSITIVE, &nd)) error = path_walk(jfsroot, &nd); if (error) /* fail */ if (nd.mnt->mnt_sb->s_type != &jfs_fs_type) /* fail */ d) store the reference to nd.mnt in superblock. e) Allocate root dentry (as usual) and whatever files you want (just pull the example from fs/binfmt_misc.c in -ac). f) Make read/write on these files whatever you want them to do - you can access the superblock of "master" JFS (see below) via the saved value of nd.mnt (d). g) in jfsmeta_put_super() do mntput() on pointer saved in (d).
How it can be used? Well, say it you've mounted JFS on /usr/local % mount -t jfsmeta none /mnt -o jfsroot=/usr/local % ls /mnt stats control bootcode whatever_I_bloody_want % cat /mnt/stats master is on /usr/local fragmentation = 5% 696942 reads, yodda, yodda % echo "defrag 69 whatever 42 13" > /mnt/control % umount /mnt
That may look like an overkill, however * You can get rid of any need to register ioctls, etc. * You can add debugging/whatever at any moment with no need to update any utilities - everything is available from plain shell * You can conveniently view whatever metadata you want - no need to shove everything into ioctls on one object. * You can use normal permissions control - just set appropriate permission bits for objects on jfsmeta
IOW, you can get normal filesystem view (meaning that you have all usual UNIX toolkit available) for per-fs control stuff. And keep the ability to do proper locking - it's the same driver that handles the main fs and you have access to superblock. No need to change the API - everything is already there... I'll post an example patch for ext2 (safe access to superblock, group descriptors, inode table and bitmaps on a live fs) after this weekend (== when misc shit will somewhat settle down). Cheers, Al
PS: Folks[1], I hope it explains why I'm very sceptical about "let's add new A{B,P}I" sort of ideas - approach above can be used for almost all stuff I've seen proposed. You can have multiple views of the same object. And have all of them available via normal API.
[1] Hans, in particular ;-) Basically, that's the idea you keep mentioning - _everything can be represented as fs_. Take it one step further and you'll get _and the beauty of that is in the fact that you don't need new tools to use the thing - generic ones are fine_
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |