I think so, if I understand what you're saying. You keep "thin" inodes
in your filter FSes (like lofs). For each entry in the dcache for the
mounted lofs (for example), you have a thin inode which has a
reference to the underlying inode?
> This is the way the BSD "null" file system works (having talked to
> the author). It does not impose a significant penalty, as there is
> almost nothing to do! But you have to do it often, once for each
> method, slightly differently each time.
Oh, yeah. Just what do the "nullfs" and "deadfs" filesystems in BSD
do, anyway?
> By "API" I mean a calling interface. E.g. the clients of the VFS
> are littered with
>
> if (inode->i_op && inode->i_op->method)
> err = inode->i_op->method(inode, ...)
> else
> err = -ESOMETHING;
>
> and it would be tidier, and more maintainable, if they said
>
> err = vfs_method(inode, ...);
>
> instead. This also allows insulation from VFS changes, by having
> the tests for numerous alternative i_op functions be elegantly
> concealed within the vfs_* wrapper, most modern alternative first.
Nice.
> Other filters include recode on filenames, recode on text data (two
> filters, stack 'em if you want both), dos-izing and un-dos-izing
> text files, ... The list goes on. But that's all window dressing;
> my big interest is hierachical storage management.
Oh! Great! That's also one of the projects I had in my ToDo/wish
list. HSM for Linux would be fantastic!
[Lots of other good ideas snipped. Wonderful creativity]
Regards,
Richard....
-
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/