Re: panic: LK_RETRY set with incompatible flags

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