Re: MPSAFE VFS -- List of upcoming actions

From: Attilio Rao <attilio_at_freebsd.org>
Date: Mon, 2 Jul 2012 15:22:23 +0100
2012/7/2, Christoph Hellwig <hch_at_infradead.org>:
> 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.

Basically when it cames to make a MPSAFE filesystem under FreeBSD
there are 2 things to pay attention at: filesystem specific locking
and dealing with FreeBSD's VFS locking.
The former is usually the tricky part because it varies among the
filesystems and it is where the developers might have more knowledge.
The latter can be helped by testing with a debugging kernel for low
hanging fruits, but special attention must be put in things like avoid
to put half-constructed vnodes in the mount lists, lookup races (in
particular with DOTDOT case) and others. For a reference, one can
always look to simple filesystems that are already made MPSAFE (like
MSDOS-FS likely).

In the XFS case, I think it would be desirable to have a real
maintainership. This means, basically, not only work on the locking
but really be keen to have a working XFS. At the moment, we might
still have write support as well, but it is badly broken. What I
suggest for XFS is:
- Remove the current write support entirely
- Try to bring the sole read support to new(ish) XFS version (at least
to a version that is known to not be totally broken)
- Fix up the support to work with FreeBSD VFS

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
Received on Mon Jul 02 2012 - 12:22:25 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:28 UTC