VFS KPI was Re: [OpenAFS-devel] Re: AFS ... or equivalent ...

[Scott Long]

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