Date: Thu, 7 Feb 2013 18:33:57 -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: <1978437261.2814435.1360280037874.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <5113C764.4010902@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1978437261.2814435.1360280037874.JavaMail.root>