Date: Wed, 6 Feb 2013 10:15:49 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: Andriy Gapon <avg@FreeBSD.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, Sergey Kandaurov <pluknet@gmail.com>, FreeBSD Current <freebsd-current@FreeBSD.org> Subject: Re: panic: LK_RETRY set with incompatible flags Message-ID: <1502349220.2745137.1360163749334.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <51121EE8.3010906@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1502349220.2745137.1360163749334.JavaMail.root>