"Peter J. Braam" <braam_at_cs.cmu.edu> writes:

> iopen(dev, inode) -- return a filehandle for file inode on device dev.
> icreate(dev) -- returns the inode number of a new file on device dev.
> istat(dev, inode, statb) -- fill in the statb structure.
> iinc(dev,inode) -- increase the disk link count of the file
> idec(dev, inode) -- decrease the disk link count (remove file when 0).

I kind of like this idea since it easier to port to other OS.
(I have an Sun IPX, so linux is no option).

Once upon time I did such a thing for linux (1.2) It gave you back
a fd when you did xh_open(dev, inode), and there was also a 
xh_readdir. The problem was that the function you used to get a
new fd was static.

The above idea i think is just fine of you remeber to connect to
newly created inodes to the filesystemtree so fsck will be happy.

> Ted Tso and I discussed this over some coffee and he suggested the
> following clever solution for the implementation of the inode calls.
> Ext2 could be mounted -- either as a mount option or by modifying a
> bit in the superblock -- with a special flag "rawinode".  Raw inode
> uses some "reserved" filenames which allow for the following:

Still, not all people will run linux, I guess that you should
create a way to put wrappers around all this so your server
dont know what it's using. But why create two interfaces ?

> This lookup will be called and will -- without consulting -- the
> /mntpnt directory return ENOENT, upon which ext2_create is called.
> Create treats the name as a special case and finds an unused inode and
> allocates it.  Now we face two choices.  Either we put a bogus name
> __#inoname#__4712 in the /mntpnt directory (in which case e2fsck will
> work fine), or we do not create a name in the directory, in which case
> we need to modify fsck a bit (not a problem either) to not consider
> the inode lost.  In fact we could ask Ted Tso for a bit in the
> superblock to indicate that fsck should not move lose inodes to
> lost+found. I think it is better not to create a funny name but to
> modify fsck.

But you could hide way those files in a . directory that the
user ^H^H^H admin never sees. But forgetting to replace
your fsck after an os upgrade, and then running the dumb fsck
on your coda partition is no fun.

autoconf test to test if we are using right version of fsck ?

Love