[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/
This archive was generated by hypermail 2b29 : Fri Mar 23 2001 - 21:00:18 EST