Re: [RFC] sane access to per-fs metadata (was Re:

[Dave Kleikamp]

Al,
I didn't know that creating file system ioctl's was such a hot topic. 
Since the functions I want to implement are for a very specific purpose
(I don't expect anything except the JFS utilities to invoke them), I
would expect an ioctl to be an appropriate vehicle.

If not ioctl's, why not procfs?  Your proposal is that each filesystem
implements its own mini-procfs.  What's the advantage of that?

My intentions so far are to use ioctl's for specific operations required
by the JFS utilities, and procfs for debugging output, tuning, and
anything else that make sense.

Alexander Viro wrote:
> That may look like an overkill, however
>         * You can get rid of any need to register ioctls, etc.

This is a one-time thing

>         * You can add debugging/whatever at any moment with no need to
>           update any utilities - everything is available from plain shell

We can do this with procfs right now.

>         * You can conveniently view whatever metadata you want - no need to
>           shove everything into ioctls on one object.

Again, why re-invent procfs?  We could put this under
/proc/fs/jfs/metadata.

>         * 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'm not sure how a utility would make atomic changes to several pieces
of metadata.  The underlying fs code would protect the integrity of
every metadata "file", but changes to more than one of these "files"
would not be done as a group without some additional locking that would
have to be coordinated between the utility and the fs.  This kind of
thing could be handled by writing some special command to a
"command-processor" type file, but why is this better than an ioctl?

-- 
David Kleikamp
IBM Linux Technology Center