> B) Inode calls.
> ---------------
It should be a relatively simple thing to add a VFS layer'ed IFS
that sites on top of a standard FS to give direct inode access.
Also one Adrian Chadd recently implemented direct inode access mode
for UFS.

 

> 
> For scalability these calls are desirable.  In fact we probably only need
> iopen, istat, idelete and I'll try to remove iinc and idec (used for copy
> on write vnodes). These inode calls are only used by the cache manager and
> the servers and don't compromise security of the system, since they should
> be restricted to root.
> 
> Ted Ts'o indeed said that Linus is probably against plain "iopen" -- and
> rightly so.  Using the special names like 'I'N'O'D'E we can let it work
> right with the VFS and dentry's etc while retaining most of the benefits
> of speed.  For Coda this will just become an optionally supported
> partition type.  

I believe this is the way Adrian did it
but with a slightly less likely string.

> 
> It should indeed be a mount option, or better perhaps something set with a
> utility in the superblock, so that fsck knows about it too. (see the
> messages of myself and Ted on linux-coda). 
> 
> C) Ext2 vs FFS vs Coda
> ----------------------
> 
> Coda needs much larger vnodes to deal with replication servers (among
> others).  We also run in user space -- mostly and use proper RVM
> transactions to guarantee (on all platforms) very high consistency on
> metadata. Effectively we are a transactional, log based system on servers. 
> We use file storage only for file data not for metadata.
> 
> On clients we also have transactions, but we don't flush them right away. 
> 
> We hope to implement write back caching where large groups of transactions
> can reach the server and improve performance by eliminating many
> transaction related fsyncs. 
> 
> It is unwise to speculate about the consistency guarantees which ext2fs
> might offer to Coda versus ffs -- without considering RVM.  The Coda meta
> data will be treated identically through RVM, on all platforms.  The file
> data might be slightly more at risk in ext2fs (although I believe that ffs
> and extfs mostly differ in the handling of metadata).

With the addoption of the Ganger/Patt Dependeancey tracking code in the
FreeBSD FFS (implemented by Kirk mcKusick), you will find the behaviour
of the FFS extremely different to what you are used to.

possibly the implementation of a central file-locking mechaninsm
(for use by nfs, ufs, samba and netatalk) might also be of interest to
you.

> 
> I hope this clarifies some of the recent discussions. 
> 
> Thank you very much for all your enthusiasm -- that makes us very happy of
> course.
> 
> - Peter Braam -
> Senior Systems Scientist 
> Coda Project, SCS, CMU
> 
> 
> To Unsubscribe: send mail to majordomo_at_FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
>