From owner-freebsd-fs@FreeBSD.ORG Sun Jun 8 07:25:50 2003 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4DF237B401 for ; Sun, 8 Jun 2003 07:25:50 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4515E43F75 for ; Sun, 8 Jun 2003 07:25:49 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h58EOSOn073312; Sun, 8 Jun 2003 10:24:28 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)h58EORiw073309; Sun, 8 Jun 2003 10:24:28 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 8 Jun 2003 10:24:27 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Brooks Davis In-Reply-To: <20030606235247.GA29775@Odin.AC.HMC.Edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: fs@freebsd.org Subject: Re: IFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2003 14:25:51 -0000 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@fledge.watson.org Network Associates Laboratories