panic: LK_RETRY set with incompatible flags

[Andriy Gapon]

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