From owner-freebsd-current@FreeBSD.ORG Wed Feb 6 01:30:03 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 81EDE16B; Wed, 6 Feb 2013 01:30:03 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 3772F338; Wed, 6 Feb 2013 01:30:03 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAByxEVGDaFvO/2dsb2JhbABFhki5OHOCHwEBAQQBAQEgBCcgCxsOCgICDRkCKQEJJgYIBwQBHASHcAyoNYJAkBeBI4wAgyWBEwOIZosJgjKBHYg4hn2DHIFRNQ X-IronPort-AV: E=Sophos;i="4.84,612,1355115600"; d="scan'208";a="12632084" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 05 Feb 2013 20:30:02 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 67A04B3F14; Tue, 5 Feb 2013 20:30:02 -0500 (EST) Date: Tue, 5 Feb 2013 20:30:02 -0500 (EST) From: Rick Macklem To: Sergey Kandaurov Message-ID: <1283189660.2731919.1360114202411.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: panic: LK_RETRY set with incompatible flags MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Konstantin Belousov , FreeBSD Current , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 01:30:03 -0000 Sergey Kandaurov wrote: > On 5 February 2013 04:13, Rick Macklem wrote: > > Sergey Kandaurov wrote: > >> On 4 February 2013 06:32, Rick Macklem > >> wrote: > >> > Konstantin Belousov wrote: > >> >> On Sat, Feb 02, 2013 at 09:30:39PM -0500, Rick Macklem wrote: > >> >> > Andriy Gapon wrote: > >> >> > > on 31/01/2013 15:29 Sergey Kandaurov said the following: > >> >> > > > Hi. > >> >> > > > > >> >> > > > Got this assertion on idle NFS server while `ls -la > >> >> > > > /.zfs/shares/' > >> >> > > > issued on NFS client. > >> > Ok, here's a snippet of zfs_dirlook() from zfs_dir.c: > >> > 388 } else if (name[0] == '.' && name[1] == '.' && name[2] == 0) > >> > { > >> > 389 zfsvfs_t *zfsvfs = dzp->z_zfsvfs; > >> > 390 > >> > 391 /* > >> > 392 * If we are a snapshot mounted under .zfs, return > >> > 393 * the vp for the snapshot directory. > >> > 394 */ > >> > 395 if ((error = sa_lookup(dzp->z_sa_hdl, > >> > 396 SA_ZPL_PARENT(zfsvfs), &parent, sizeof (parent))) != 0) > >> > 397 return (error); > >> > 398 if (parent == dzp->z_id && zfsvfs->z_parent != zfsvfs) { > >> > 399 error = zfsctl_root_lookup(zfsvfs->z_parent->z_ctldir, > >> > 400 "snapshot", vpp, NULL, 0, NULL, kcred, > >> > 401 NULL, NULL, NULL); > >> > 402 return (error); > >> > 403 } > >> > > >> > Just reading the comment, I don't know what it is referring to by > >> > "snapshot directory". Would that be "shares" for Sergey's case? > >> > > >> > It seems too obvious, but maybe the lookup of ".." is returning > >> > the > >> > vnode for /.zfs/shares for this case? > >> > > >> > I don't know why this wouldn't have shown up before, but maybe it > >> > usually > >> > replies from its cache (I think zfs_lookup() calls it a "fast > >> > path"). > >> > > >> > It might still be interesting to replace zfs_vnops.c line# 1451 > >> > with: > >> > if ((cnp->cn_flags & ISDOTDOT) && *vpp != dvp) > >> > and see what happens? > >> > > >> > >> With this change `ls /home/user1001/.zfs/shares/' lists empty > >> directory > >> (although the relevant dataset has snapshot, but that's a different > >> story :)). > >> Great! > >> Nothing panics/asserts/etc, just seemingly unrelated LOR > >> > > Yes, I think the patch is relatively safe, since lookup() checks for > > same vnode and does a vrele() instead of a vput() when they are the > > same, > > at least for a plain lookup without wantparent. > > > > So, since I've never used ZFS, what does a "ls -la > > /home/user1001/.zfs/shares/" > > give you when done locally one the server? > > On server (with unmodified kernel): > # ls -la /pool1/user1001/.zfs/share > total 2 > dr-xr-xr-x 2 root wheel 2 Feb 2 20:06 . > dr-xr-xr-x 4 root wheel 4 Feb 2 20:06 .. > > It crashes only when .zfs/share is accessed via NFS > (with and without snapshots), and not when accessed locally. > I'm not surprised. If it crashed for local accesses, I would suspect people would have reported it much sooner. I also suspect it only happens for NFSv4 mounts, since those try and cross server mount points. Since I don't understand ZFS, I have just posted a query on freebsd-fs@, which I hope will get noticed by people who may know why ZFS is doing this. rick > -- > wbr, > pluknet > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org"