Re: ZFS vs NetBSD vnode recycling

[haad <haaaad%gmail.com@localhost>]

On Fri, Oct 16, 2009 at 10:29 AM, Matthias Scheler 
<tron%zhadum.org.uk@localhost> wrote:
> On Tue, Oct 13, 2009 at 12:02:58PM +0200, Adam Hamsik wrote:
>> 1) Defer calling of zfs_zinactive, to system taskq, which can later
>> destroy znode. I have tested this version and it works but I'm getting
>> deadlock. I need to investigate it, if it is caused by my change or not.
>
> Can that cause temporary resource starvation if a lot of vnodes need to
> be allocated and the taskq is not currently active?
>
>> 2) Some sort of vreclaim patch(disable vnode recycling and just call
>> vnalloc in getnewvnode), which will be done right this time. I'm
>> willing to do it but I'm not sure how it should be done.
>
> Do you propose to remove the global vnode table and associate vnodes
> directly with the invidiual file-system? The BSD 4.4 book claims this
> bad because you can end up having a lot of vnodes used by a file-system
> that is currently idle.
>
>> 3) Do it like FreeBSD does it. They do almost the same like we in 1.
>> But they do it differently.
>
> Let me see if I understand this code:
> 1.) If it can get the locks it immediately reclaims the vnode.
> 2.) If it cannot get the lock it defers reclaiming the vnode to
> Â Âa taskq.
>
> That sounds like a better approach than your first suggestion because
> it will (hopefully) avoid the overhead and delay in most cases.

That approach seems like a hack to me because MUTEX_HELD should not be
used for locking decisions, but we are doing the same in 1 and 3. If
mutex which I want to lock is already locked by me I defer
zfs_zinactive to taskq.

Problem is that with this change I will get another deadlock later and
I need to investigate if it is casused by my change or by another
problem in NetBSD/zfs compatibility.



-- 


Regards.

Adam