From owner-freebsd-current@FreeBSD.ORG Wed Feb 6 15:15:51 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A8EC2AF7; Wed, 6 Feb 2013 15:15:51 +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 5FA7217D; Wed, 6 Feb 2013 15:15:50 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAHtyElGDaFvO/2dsb2JhbABFhki6EnOCHwEBAQMBAQEBIAQnIAsFFg4KAgINGQIpAQkmBggHBAEcBIdqBgypR5JdgSOMAIMlgRMDiGaLCYIygR2IOIZ9gxyBUTU X-IronPort-AV: E=Sophos;i="4.84,615,1355115600"; d="scan'208";a="12709974" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 06 Feb 2013 10:15:49 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 574E6B3F4A; Wed, 6 Feb 2013 10:15:49 -0500 (EST) Date: Wed, 6 Feb 2013 10:15:49 -0500 (EST) From: Rick Macklem To: Andriy Gapon Message-ID: <1502349220.2745137.1360163749334.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <51121EE8.3010906@FreeBSD.org> 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.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Konstantin Belousov , Sergey Kandaurov , FreeBSD Current 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 15:15:51 -0000 Andriy Gapon wrote: > on 06/02/2013 03:30 Rick Macklem said the following: > > 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. > > Actually I think I have an explanation, just been busy past couple of > days. > The problem is precisely with .zfs/shares, which is a strange beast > that > currently has no practical use on FreeBSD. > > .zfs/shares has its own on-disk node. The node has some special > properties: > - it is a directory node > - it is not reachable from any other node > - its parent ID is set to itself (as for a root node) > - its ID is stored in a special filesystem property > > At run time ZFS creates special vnodes for .zfs, .zfs/snapshot and > .zfs/shares. > The vnodes are special is a sense that each of them has its own v_ops > different > from v_ops of the regular ZFS vnodes. > For example, vop_lookup method of .zfs/shares should return the .zfs > vnode for a > ".." lookup. The v_ops are sane and self-consistent and everything is > supposed > to work fine with them and provide some ".zfs magic". > > Except for one hole. The .zfs/shares vnode has the same inode number > as the > on-disk node. Also, its vop_vptofh generates fid_t consistent with the > on-disk > node. > Then, ZFS vfs_fhtovp has a special case to do the right thing for > fid_t-s of > .zfs and .zfs/snapshot. But for some reason there is no special code > for > .zfs/shares. And so a regular ZFS vnode is created/returned in that > case. > > And this is the problem. > > Regular zfs_lookup for ".." in this vnode returns the vnode itself > because of > the magic properties described in the beginning. And so on. > > We seem to have inherited this problem from the upstream: > http://thread.gmane.org/gmane.os.illumos.zfs/599 > > I believe that currently NFS is the only user of VOP_FID and > VFS_FHTOVP. > There are also getfh(2), lgetfh(2) and fhopen(2), but I am not sure > how widely > they are used. > > In either case, I believe that zfs_fhtovp should grow a check for > object == > zfsvfs->z_shares_dir and return the "made up" .zfs/shares vnode in > that case > (instead of a regular zfs vnode). > Ok, great. Thanks for the good explanation. > Additionally, I am not sure, but perhaps zfs_vget() should do the same > kind of > tricks as zfs_fhtovp. > 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. Thanks again for the explanation, rick > -- > Andriy Gapon > _______________________________________________ > 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"