Re: MPSAFE VFS -- List of upcoming actions

On 7/2/12 10:03 AM, Alexander Kabaev wrote:
> On Mon, Jul 02, 2012 at 02:12:20AM -0400, Christoph Hellwig wrote:
>> On Sun, Jul 01, 2012 at 03:52:05PM +0200, Attilio Rao wrote:
>>> anything by SoC involved people about NTFS and certainly I don't see a
>>> plan to get XFS locked.
>>
>> Stupid question, but what amount of locking does XFS in FreeBSD still
>> need?  I'm one of the maintainer of XFS on Linux, and while I know
>> FreeBSD imported a really old version compared to the current one the
>> codebases on IRIX and later Linux never relied on any global Giant-style
>> locking.  So if there is anything to fix it would be the in the small
>> bits of FreeBSD-specific code.
>>
> 
> When I stopped being interested in XFS, I left is marked as non-MPSAFE
> entirely because of the lack of proper testing and because VFS locking
> was still evolving, there was no officially proper way of locking the
> FS and no other FS in the tree was MPSAFE. At that time the only
> problematic area was around inode instantiation, but sereval other
> lockingi changes have made it into the tree since then, namely ones that
> deal with insmntque and also VOP_LOOKUP changes. To mark XFS MPSAFE, one
> needs to simply audit the code and make sure it still makse sense for today's
> VFS, which is not a huge amount of work. One step further woule be to take
> most of the XFS from under the exclusive vnode locking to improve the
> performance.
> 
> And there is a third option - just let current XFS port die and start with
> newer version.
> 
I like option 3.
The current code is way way out of date and doesn't even reflect the
last round of sync up I did. Unless somebody says "hey I'm using XFS" we
could just let the current code go and reintroduce a current port
if it ever receives the needed attention.

Unfortunately I think there were would have be be some sponsorship of
the effort since getting xfs fully supported would require some
significant developer hours.

If anybody is interesting in the current state of things here is my git
tree that I cleaned up and put online during BSDCan.
http://git.digitalelves.com/?p=FreeBSD_xfs.git;a=summary

xfs-FreeBSD_7 has the last somewhat functional code.
This was based on a code drop from linux XFS at the time.

Log recovery was just starting to come to life (very simple recovery
would work)
Write was working to the point there you could do a single thread to the
fs and have the data cmp back with the original file.

Read also still works but is unstable.

xfs-FreeBSD_9 is quick code drop I did a month or so ago.
I does not compile as many of the linux files moved around so
not all the compat stuff lines up and some new compat code needs
to written.

-Russell