Date: Thu, 07 Feb 2013 17:25:24 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Rick Macklem <rmacklem@uoguelph.ca> 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: <5113C764.4010902@FreeBSD.org> In-Reply-To: <236652418.2788560.1360249464612.JavaMail.root@erie.cs.uoguelph.ca> References: <236652418.2788560.1360249464612.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5113C764.4010902>