IFS

[Robert Watson]

On Fri, 6 Jun 2003, Brooks Davis wrote:

> Does anyone know of any efforts to reimplement IFS on UFS2 or have a
> good idea how much work it would be?  I'm wondering because we have an
> application where where a fully current UFS2 based IFS is close to a
> perfect fit.  The application is the Storage Resource Broker which uses
> a relational database to store metadata indexing for files in a variety
> of storage methods.  The main online storage method uses the usual trick
> of hashing into directories.  We should be able to get by with that, but
> IFS seems like a much better fit. 
> 
> This year we're buying about 12TB of storage that I'm going to be
> running FreeBSD on (4U, 16 drive IDE systems).  Next year, we hope to
> buy 160TB and the final project will us on the order of 2PB of NASA
> satellite data and processed data products.  Fortunatly for us, most
> files are big (about 1GB). 

Well, doing the IFS work again will probably be a moderate amount of work,
although it could well be worthwhile.  One of the things I particularly
like about IFS is that it permits a useful access control model to be used
for allocation/removal/... of objects in the store, and doesn't require a
privileged interface.  It was one of the only uses of the UFS/FFS
separation that really justified the split, in my view :-).

If the namespace costs for repeated lookups are causing you trouble in the
short term, you could use the fh*()  interface to look up by NFS file
handle instead of by pathname.  That doesn't help you with namespace
manipulation costs, since you still use the normal name.  When an object
is created, use getfh() to cache the handle in a database.  Later, use
fhopen() to open the object using the handle.  One downside to this
interface is that the process performing the lookups needs to run as root,
whereas IFS could support other models and scoping more easily.

AFS has variously depended on special system calls to open by-inode and
made use of a modified file system check that ignores detached AFS inodes
not hooked up the namespace. 

Darwin supports a volfs, which supports the lookup of objects using
/.vol/fsid/inodenum for HFS+, which is required for compatibility with
applications that expect to use MacOS file identifiers to directly lookup
objects without walking the namespace so that they can maintain persistent
references to objects even when they change location on the file system. 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Network Associates Laboratories