Deadlock in nullfs/zfs somewhere

[Andriy Gapon]

on 17/07/2013 20:19 Adrian Chadd said the following:
> On 17 July 2013 04:26, Andriy Gapon <avg at freebsd.org> wrote:
>> One possibility is to add getnewvnode_reserve() calls before the ZFS transaction
>> beginnings in the places where a new vnode/znode may have to be allocated within
>> a transaction.
>> This looks like a quick and cheap solution but it makes the code somewhat messier.
>>
>> Another possibility is to change something in VFS machinery, so that VOP_RECLAIM
>> getting blocked for one filesystem does not prevent vnode allocation for other
>> filesystems.
>>
>> I could think of other possible solutions via infrastructural changes in VFS or
>> ZFS...
> 
> Well, what do others think? This seems like a showstopper for systems
> with lots and lots of ZFS filesystems doing lots and lots of activity.
> 

Looks like others are not speaking yet :-)

My current idea is that ZFS should set MNTK_SUSPEND in zfs_suspend_fs() path
before acquiring its z_teardown* locks.  This should make intentions of ZFS
visible to VFS.  And thus it should prevent VOP_RECLAIM call on a suspended ZFS
filesystem and that should prevent vnlru_free() getting stuck.
Hopefully this should break the deadlock cycle.

Kostik,

what is your opinion?
For your convenience here is a message with my analysis of this issue:
http://thread.gmane.org/gmane.os.freebsd.current/150889/focus=18534
-- 
Andriy Gapon