MPSAFE VFS -- List of upcoming actions
Locked
12
12
 
|
|
|
|
|
|
|
|
|
|
|
On 7/2/12 1:12 AM, 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. > with regards to filesystems is about. XFS certainly maintained any fine grain locking inherent to XFS it self. The XFS locks were mapped to FreeBSD sx locks in the code that is in the tree currently. The last time I made a pass at updating XFS some of locks were remapped to mtx locks. Is there somethings in the vfs layer in terms of locking that needs to be pushed down to the fs? -Russell |
signature.asc (267 bytes) |
|
|
|
|
In reply to this post by Christoph Hellwig
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. > 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. -- Alexander Kabaev |
|
On Mon, Jul 02, 2012 at 11:03:40AM -0400, 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. placed after the vnode locks in global lock order, because VOP methods call into fs with vnode locked. Then, VOP_LOOKUP() usual sequence of events, when method is called with lookup directory locked, causes LOR. It appears because you lock global lock upon entry into VOP_LOOKUP(), and then need to lock the returned vnode. Dropping global lock inside VOP_LOOKUP() usually exposes races which were the reason to introduce the global lock. Having filesystem non-MPSAFE makes the LOR go away without the need to drop global lock. Example of FreeBSD native filesystem which suffered from this issue and required quite non-trivial handling is devfs. Devfs uses per-mount global lock. See devfs_allocv() and devfs_allocv_drop_refs() for the gory details. |
|
|
In reply to this post by Alexander Kabaev-3
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. > 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 |
|
|
In reply to this post by Konstantin Belousov
On Mon, 2 Jul 2012 23:12:06 +0300
Konstantin Belousov <[hidden email]> wrote: > On Mon, Jul 02, 2012 at 11:03:40AM -0400, 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. > > If filesystem uses some global internal locks, that locks usually are > placed after the vnode locks in global lock order, because VOP methods > call into fs with vnode locked. Then, VOP_LOOKUP() usual sequence of > events, when method is called with lookup directory locked, causes > LOR. It appears because you lock global lock upon entry into > VOP_LOOKUP(), and then need to lock the returned vnode. > Dropping global lock inside VOP_LOOKUP() usually exposes races which > were the reason to introduce the global lock. Having filesystem > non-MPSAFE makes the LOR go away without the need to drop global lock. > > Example of FreeBSD native filesystem which suffered from this issue > and required quite non-trivial handling is devfs. Devfs uses per-mount > global lock. See devfs_allocv() and devfs_allocv_drop_refs() for > the gory details. global lock internally, it is quite well locked inside and exclusive _VNODE_ lock we take by default in all methods is usually unnecessary as all it does it prevents other locks in XFS proper from having any useful function. -- Alexander Kabaev |
|
|
|
|
|
|
|
|
Loading...
| Powered by Nabble | Edit this page |