From owner-freebsd-current@FreeBSD.ORG  Thu Feb  7 23:34:24 2013
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 6D756CD9;
 Thu,  7 Feb 2013 23:34:24 +0000 (UTC)
 (envelope-from rmacklem@uoguelph.ca)
Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca
 [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0FF0C72E;
 Thu,  7 Feb 2013 23:34:23 +0000 (UTC)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqAEALo5FFGDaFvO/2dsb2JhbABFhkm2RoQAc4IfAQEFIwRSGw4KAgINGQJZBogkrWiSUIEjjyaBEwOIZo07iVWGfYMeggY
X-IronPort-AV: E=Sophos;i="4.84,625,1355115600"; d="scan'208";a="15670865"
Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca)
 ([131.104.91.206])
 by esa-jnhn.mail.uoguelph.ca with ESMTP; 07 Feb 2013 18:33:57 -0500
Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1])
 by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id D882FB4046;
 Thu,  7 Feb 2013 18:33:57 -0500 (EST)
Date: Thu, 7 Feb 2013 18:33:57 -0500 (EST)
From: Rick Macklem <rmacklem@uoguelph.ca>
To: Andriy Gapon <avg@FreeBSD.org>
Message-ID: <1978437261.2814435.1360280037874.JavaMail.root@erie.cs.uoguelph.ca>
In-Reply-To: <5113C764.4010902@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.203]
X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692)
Cc: Konstantin Belousov <kostikbel@gmail.com>,
 Sergey Kandaurov <pluknet@gmail.com>,
 FreeBSD Current <freebsd-current@FreeBSD.org>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
 <freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>, 
 <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
 <mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2013 23:34:24 -0000

Andriy Gapon wrote:
> on 07/02/2013 17:04 Rick Macklem said the following:
> > The other thing I wondered about is "can zfsvfs->z_shares_dir ever
> > not
> > fit in 32bits?".
> 
> Usually it should be one of the first objects created in a new
> filesystem, so it
> should have a small ID (typically 7).
> 
> > I notice it is a uint64_t, but ino_t is still 32bits for
> > FreeBSD. If it didn't fit in 32bits, the check in zfs_vget()
> > wouldn't
> > work. (I have a hunch that, for now, the ZFS code doesn't exceed
> > 32bit
> > fids, but haven't looked at the code to try and see. I'll take a
> > closer
> > look at that, too.)
> 
> As far as I understand, ZFS actually uses 48 bits for object IDs at
> the moment.
> Since they are generated incrementally they do not overflow 32 bits
> soon.
> But you are right that this is a potential problem as long as ino_t
> stays 32-bit.
> 
> However, it seems that VFS_VGET is mostly used by filesystem drivers
> internally.
> And ZFS doesn't seem to do that.
> The only external user appears to be NFS.
> 
Cool. Sounds fine, rick

> --
> Andriy Gapon