Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 15 May 2002 09:53:54 -0400 (EDT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        Julian Elischer <julian@elischer.org>, arch@FreeBSD.org
Subject:   Re: Future of IFS
Message-ID:  <Pine.NEB.3.96L.1020515094457.80385D-100000@fledge.watson.org>
In-Reply-To: <3CE1FCFE.A2602D49@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Tue, 14 May 2002, Terry Lambert wrote:

> Robert Watson wrote:
> > My impression from my conversation with him was that if he did start
> > maintaining IFS again, it would be a re-implementation for 5.0.  I'm
> > concerned that in its current state, we will be unable to make progress on
> > UFS2.
> 
> At first glance, I find this answer surprising. 
> <... observations about exposing interfaces at various levels>
> In fact, since the on disk dirent and the system call exposed dirent are
> only intentionally "coincidentally" equal... the same for the stuctures
> used by getattr/setattr/stat... it should be possible to implement a
> UFS2 in FreeBSD without really changing *any* of the exposed interfaces
> seen by user space, except later, to get at UFS2 specific features, so
> the work could even be staged to reduce overall risk.  Every FS that
> isn't FFS (and therefore doesn't "coincidently"  luck out) already does
> explicit conversions.  Breaking the historical "coincidence" for a new
> FS seems to be a logical way of achieving ABI/API compatability. 
> 
> Please correct me if my logic is way off base. 

The problem is that IFS is highly "in bed" with FFS/UFS with respects to
the internal kernel interfaces.  Arguably, that's not actually a problem
except in the context if the current work, in fact :-).  The
implementation is small -- just over a thousand lines, and it largely
works by plugging into existing FFS functionality by either referring to
FFS or UFS vnode operations in its operation arrays, or by directly
hooking into FFS inode/file system structure details and interfaces so it
can generate directory information and invoke file system meta-data calls. 
The problem isn't at the userland interface, where (as you surmise) the
first step will simply be to use largely the same interfaces already
exposed, but in the inter-FFS/UFS interface layer, where there are
substantial changes in how UFS and FFS talk to each other.  It doesn't
seem to me that it would be all that "hard" to update IFS for the new
environment, but it will take someone willing to commit to doing the work.

As I said, there are really two options following the UFS2 commit: 
disconnect it from the build if the maintainer hasn't updated it yet, or
remove it until the maintainer replaces it.  If Adrian is willing to do
the work, that's great; if he's not, we'll need to find a maintainer. But
even if he is the maintainer, my impression from a conversation with him
is that he plans to reimplement it *anyway*, making removal of the current
IFS non-harmful during the "UFS2 is added but before IFS is replaced"
window.  In the event he does plan to "start from" the current code, it
will all still be there in the Attic where it can be easily recovered
(some files never die...).  Another choice would be for the maintainer to
do what is being done from ext2fs: divorce it from the UFS implementation
entirely, so that it does get mixed up in the UFS/FFS changes. 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org      NAI Labs, Safeport Network Services




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020515094457.80385D-100000>