On Oct,Friday 30 2009, at 12:25 AM, Bill Stouder-Studenmund wrote:
On Thu, Oct 29, 2009 at 11:58:32PM +0100, Adam Hamsik wrote:
On Oct,Thursday 29 2009, at 8:15 PM, David Laight wrote:
On Wed, Oct 28, 2009 at 11:44:51PM +0000, Adam Hamsik wrote:
Module Name: src
Committed By: haad
Date: Wed Oct 28 23:44:51 UTC 2009
Modified Files:
src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_vnops.c
zfs_znode.c
Log Message:
Add workaround about zfs vnode reclaiming deadlock by checking if
we don't
ehld ZFS_MUTEX_OBJ already. If we can lock OBJ_MUTEX deffer
execution of
zfs_zinactive to taskq. Code was inspired by FreeBSD
zfs_freebsd_reclaim.
This doesn't sound right at all ...
If the 'If we can lock OBJ_MUTEX' test is a try_mutex_enter() then
it may fail because another lwp owns it ...
I hope it is only the checkin comment that is inverted!
There are 3 option which can happen
1) Our lwp already holds mutex
2) mutex is not held at all
3) Another LWP holds it
In case 1 we can call reclaim vnode, in case 2 we lock it with
try_mutex_enter and reclaim it and in case 3 we use taskq for
reclaiming of vnode.
This is reclaiming in response to someone trying to get a cleaned
vnode,
correct? If so, we should just change the reclaim API and return
something
like EBUSY. If it's just cleaning to clean, then having a taskq do
it is
fine.
That can be done but ti will require to change all fses +
getcleanvnode because currently when it can't clean vnode it panics.
Where you able to look at the repository at macosforge.org before it
shut
down? I think that would show a take at solving similar issues.
Yeah I have it somewhere around here, but as I noted I used freebsd
version as a working example for this patch.
Regards
Adam.