In message <10005232128.ZM122979@rlyeh.engr.sgi.com>, "Rusty Ballinger" writes:
> ezk:
> > rusty:
> > > willy:
> > > > What I'd like to do would be to stack a notification layer on top of
> > > > a directory, which would actually just entail replacing its ->i_op
> > > > with a shim which notified and then passed the call on.
> ...
> > > If modules could easily replace ->i_op (preferably without stomping each
> > > other), you could load modules which did whatever they wanted in response
> > > to various operations on specific inodes
> ...
> > What you're describing is called stackable file systems, which I've created
> > under Linux. I have an encryption f/s, compression f/s, and several other
> > samples---all built on top of "generic" stacking templates. See
> >
> > http://www.cs.columbia.edu/~ezk/research/fist/
>
> Is there a way to wrap operations on a single file or directory without
> affecting operations on other files in or below that directory? If I
> understand correctly, you'd have to overlay mount your wrapfs-fs on the
> file's directory, and on every subsequent operation on files under that
> mount point, determine whether or not the operation was on the inode(s)
> you were interested in. That's an improvement over the way imon works
> now, and I will try it out, but I'd prefer it to work as willy described.
>
> --Rusty
It's possible to do what you want, but it complicates stacking considerably.
Consider how you'd have to carefully handle the ".." chdir case from a
non-stacked directory up to one which is (partially) stacked. You can't do
it without somehow maintaining some state in the node (inode, dentry,
whatever) of where you came from (or who is the real or desired parent). It
is easier and cleaner to stack on every file or directory, as it gives you
the opportunity to modify the behavior, data, etc. of these objects. In
addition, the performance overhead of null-layer stacking can be really
small (I measured it to be 1-2%).
If you want different behavior for certain files or directories, that can be
done. You can start w/ the default null-layer stackable f/s (nullfs, lofs,
wrapfs, whatever the name happens to be that week :-) and you apply your
changed behavior for given files or directories based on their name. You
can store different operations vectors (->i_op, ->f_op, ->d_op, etc.) for
the files you want to change, and default to the pass-through null-layer ops
for all others.
Ion and I used such a technique in usenetfs, a stackable f/s that breaks
large flat USENET directories into a deeper hierarchy of directories based
on a hash of the article file name. So for example, the article
control/cancel/123456 was transparently moved to control/cancel/345/123456;
this was of course to improve access to these large flat directories w/o
changing the format of the low-level f/s. But we didn't want to do it for
all article directories, only for those which were really large on our news
server (such as control/cancel, misc/jobs, etc.) So we devised usenetfs to
be a regular pass-through null-layer f/s, and only turn on the special
nested directory structure code for directories that were flagged that way;
we co-opted the (seldom-used) setuid bit on directories as our trigger.
Erez.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:13 EST