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>