From owner-freebsd-current@FreeBSD.ORG Thu Feb 7 15:25:29 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 C9330D3F for ; Thu, 7 Feb 2013 15:25:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0415782C for ; Thu, 7 Feb 2013 15:25:28 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA00509; Thu, 07 Feb 2013 17:25:25 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <5113C764.4010902@FreeBSD.org> Date: Thu, 07 Feb 2013 17:25:24 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130206 Thunderbird/17.0.2 MIME-Version: 1.0 To: Rick Macklem Subject: Re: panic: LK_RETRY set with incompatible flags References: <236652418.2788560.1360249464612.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <236652418.2788560.1360249464612.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: Thu, 07 Feb 2013 15:25:29 -0000 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. -- Andriy Gapon