panic: LK_RETRY set with incompatible flags
pluknet at gmail.com
Thu Feb 7 15:37:02 UTC 2013
On 7 February 2013 17:43, Andriy Gapon <avg at freebsd.org> wrote:
> on 07/02/2013 04:13 Rick Macklem said the following:
>> Andriy Gapon wrote:
>>> on 06/02/2013 17:15 Rick Macklem said the following:
>>>> Well, zfs_vget() returns EOPNOTSUPP for .zfs, so the NFS server
>>>> knows to
>>>> switch over to using VOP_LOOKUP(). If the .zfs/snapshot and
>>>> do the same thing, that should be fine, at least for the NFS server,
>>>> I think.
>>> Ah, right, but again this is done only for .zfs and .zfs/snapshot.
>>> .zfs/shares is not special-cased and thus is problematic here too in
>>> the same
>>> fashion as zfs_fhtovp.
>> Well, I have no way to test this, but maybe the attached patch is a
>> start in the right direction.
>> Maybe you can take a look at it and/or Sergey could test it?
>> Thanks for all your help with this, rick
> the patch looks 99% percent good to me :-)
> I am not sure if I am overly paranoid here, but I would add a check for
> zfsvfs->z_shares_dir being non-zero before comparing anything with it.
> I am also not sure if doing actual zfs_zget only to check zp_gen != fid_gen or
> z_unlinked is required. Probably not.
> could you please test Rick's patch?
Hi Rick, Andriy.
I tested the patch without the (*vpp != dvp) change.
It works well.
It's something unrelated but when doing ls -l
on server (patched) and client (unpatched) sides,
I found some inconsistency in returned stats.
Or more precisely:
# stat -s /pool1/user1000/.zfs/shares/..
st_dev=2050684725 st_ino=1 st_mode=040555 st_nlink=4 st_uid=0 st_gid=0
st_rdev=0 st_size=4 st_atime=1360251211 st_mtime=1359551493
st_ctime=1359551493 st_birthtime=1359551493 st_blksize=4096
# stat -s /home/user1000/.zfs/shares/..
st_dev=2050684725 st_ino=7 st_mode=040555 st_nlink=2 st_uid=0 st_gid=0
st_rdev=1377468712 st_size=2 st_atime=1360251104 st_mtime=1359551493
st_ctime=1359551493 st_birthtime=-1 st_blksize=4096 st_blocks=3
More information about the freebsd-current