Re: VFS KPI was Re: Re: AFS ... or equivalent ...

Rick Macklem wrote:
> 
> 
> On Wed, 16 Jan 2008, Robert Watson wrote:
> 
> [good stuff snipped]
>>
>> Right now we maintain a relatively stable VM/VFS
KPI withing a major 
>> release (i.e, FreeBSD 6.0 -> 6.1 -> 6.2 ->
6.3), but see fairly 
>> significant changes between major releases (5.x
-> 6.x -> 7.x, etc).  
>> I expect to see further changes in VFS for 8.x (and
some of the 
>> locking-related ones have already started going
in).
>>
> This is loosely related to both the OpenAFS thread and
the Mac OS X ZFS
> port thread, so I thought I'd ask...
> 
> Has anyone considered trying to bring the FreeBSD VFS
KPI (and others, for
> that matter) closed to the Darwin/Mac OS X ones? The
Apple folks made
> quite dramatic changes to their VFS when going from
Panther (very FreeBSD
> like) to Tiger, but seemed to have stabilized, at least
for Leopard. It
> just seems that using the Mac OS X KPIs might leverage
some work being
> done on both sides? (I don't know if there is an
OpenAFS port to Mac OS X
> or interest in one, but I would think there would be a
use for one, if it
> existed?)
> 
> Although I'm far from an expert on the Mac OS X VFS
(when I ported to it,
> I just cribbed the code and it worked, it seems
that they pretty well
> got rid of the concept of a vnode-lock. If the
underlying file system 
> isn't SMP safe, it can put a lock on the subsystem at
the VFS call.
> (I think it optionally does a global lock or a uses an
smp lock in the
> vnode, but don't quote me on this. My code currently
runs with the
> thread-safe flag false in the vfs_conf structure entry,
which enables
> the automagic locking.)
> 

Both Solaris and OSX seem to have found the path out of the
VFS locking
woods, and it would indeed be really nice if FreeBSD could
follow suit.
You're not the first to suggest the vnode locking move out
of VFS and
into the filesystems.  I think that the work it would take
to adapt the
existing filesystems to this design would be far less than
the ongoing
work by everyone to fight the old design (both in FreeBSD
proper and in
companies that do their own custom filesystems in FreeBSD),
but it does
come at a cost of making things like nullfs much harder, if
not nearly
impossible.  I wish I had time to work on something like
this, but I
encourage others to look into it and experiment.

Scott
_______________________________________________
freebsd-fsfreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to
"freebsd-fs-unsubscribefreebsd.org"