*BSD News Article 10187


Return to BSD News archive

Received: by minnie.vk1xwt.ampr.org with NNTP
	id AA7354 ; Mon, 18 Jan 93 10:52:36 EST
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!sgiblab!spool.mu.edu!uunet!gatech!news.byu.edu!ux1!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: How does 386BSD implement a virtual file system switch (VFS)?
Message-ID: <1993Jan20.221238.13109@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University  (Ogden, UT)
References: <1993Jan19.222140.12508@informix.com>
Date: Wed, 20 Jan 93 22:12:38 GMT
Lines: 73

In article <1993Jan19.222140.12508@informix.com> johng@informix.com (John Galloway) writes:
>
>  The docs mention multiple file systems, but not how this is
>  accomplished (and I have yet to be able to get cpio to read
>  the source files on my Quadra-A/UX system, and have yet to purchase
>  my 486 box).  Is a virtual file system switch used like that from
>  BSD 4.3 and SYSV.4 or is it something different? thanks.

Yes, a VFS interface is used... not that this statement actually tells you
a lot: read on.

The interface is mostly like the BSD 4.3 interface, but only sorta like the
AIX VFS interface (which is mostly but not quite like the SunOS 4.1.2 VFS
interface).

It's not at all like the SVR4.0 VFS interface, and drastically different from
the SVR4.2 VFS interface, which supports SMP primitives, and also very
different from the UNIXWare VFS interface, which is the SVR4.0 interface
except that they've reduced the number of elements in the vnops table
by one for some unexplained reason, and removed a lot of kernel compatability
routines like memcpy() needed to support most stock VFS FS implementations.

It's actually possible to program something that, with a few minor #ifdef's,
will compile on all these systems, but...

The main problem is that the VFS interface is only defined "on top" --
the back-end interface to the disk is handled by the virtual memory
manager as "dirty buffers" representing the data you want to put on the
disk.  The interface to the memory management routines is different for
every system, so it's hard to make something which runs everywhere... so
even if it compiles, linking it into a real kernel is a different matter.

Finally, the problem of differing bottom-end interfaces is resolved by
the BSD 4.4 VFS, which is based on John Heidemann's (and others) work
on FICUS at UCLA... the only problem is that it only exists in a SunOS
implementation (that you can't get from UCLA without a SunOS source
license) and BSD 4.4.  Of course the problem is also solved (in an
incompatable way using vnode stacking) in David S. H. Rosenthal's
approach on pages 107-108 of the June 1990 USENIX Conference Proceedings,
for which I have yet to see a reference implementation.  The public
versions of BSD 4.4 might be made available ala Net/2 style release
at a later date, assuming particular outcomes to the USL suits against
BSDI (a minor hurdle) and UCB (a major hurdle).


The wonderful thing about standards is that there are so many to choose from.

Current practice is to either take the (unavailable without a source
license) AT&T VFS draft document and write one from scratch, or, more
commonly, pick a PD implementation and hack it.


386BSD currently supports the UFS (Berkeley), MFS (ram disk), PCFS (DOS),
NFS, and ISOFS (ISO9660) file systems.  Currently rumored to be in
development is an ISO9660 FS with RockRidge extensions (long names for UNIX,
etc.).

Current extensions to existing file systems include support for access
control lists OR locale based internationalized storage (the two use
conflicting "spare" information in the UFS inode).


					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-- 
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------