Date: Thu, 7 Feb 2013 18:36:45 +0300 From: Sergey Kandaurov <pluknet@gmail.com> To: Andriy Gapon <avg@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, Rick Macklem <rmacklem@uoguelph.ca>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: panic: LK_RETRY set with incompatible flags Message-ID: <CAE-mSOLTN7YMytwf-DqJjowSKWnX%2B-PC-vgJM1F=p0qnfVBYRg@mail.gmail.com> In-Reply-To: <5113AF89.4070303@FreeBSD.org> References: <1137922035.2777364.1360203187367.JavaMail.root@erie.cs.uoguelph.ca> <5113AF89.4070303@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7 February 2013 17:43, Andriy Gapon <avg@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 >>>> .zfs/share >>>> 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 > > 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. > > Sergey, > 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: NFS server # 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 st_blocks=0 st_flags=0 NFS client # 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 st_flags=0 JFYI. -- wbr, pluknet
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAE-mSOLTN7YMytwf-DqJjowSKWnX%2B-PC-vgJM1F=p0qnfVBYRg>