HomeFreeBSD

another rework of getzfsvfs / getzfsvfs_impl code

Description

another rework of getzfsvfs / getzfsvfs_impl code

This change is designed to account for yet another difference between
illumos and FreeBSD VFS. In FreeBSD a filesystem driver is supposed to
clean up mnt_data in its VFS_UNMOUNT method because it's the last call
into the driver before a struct mount object is destroyed. The VFS
drains all references to the object before destroying it, but for the
driver it's already as good as gone.
In contrast, illumos VFS provides another method, VFS_FREEVFS, that is
called when all references are drained. So, the driver can keep its
data after VFS_UNMOUNT and clean it up in VFS_FREEVFS after all
references are gone. This is what ZFS does on illumos.
So there a reference to a filesystem is sufficient to guarantee that the
ZFS specific data, aka zfsvfs_t, stays around (even if the filesystem
gets unmounted). In FreeBSD we need to vfs_busy the filesystem to get
the same guarantee. vfs_ref guarantees only that the struct mount is
kept.

The following rules should be observed in getzfsvfs / getzfsvfs_impl on
FreeBSD:

  • if we need access to zfsvfs_t then we must use vfs_busy
  • if only we need to access struct mount (aka vfs_t), then vfs_ref is enough
  • when illumos code actually needs only the vfs_t, they still can pass the zfsvfs_t and get the vfs_t from it; that can work in FreeBSD if the filesystem is busied, but when it's just referenced then we have to pass the vfs_t explicitly
  • we cannot call vfs_busy while holding a dataset because that creates a LOR with dp_config_rwlock

As a result:

  • getzfsvfs_impl now only references the filesystem, same as in illumos, but unlike illumos it has to return the vfs_t
  • the consumers are updated to account for the change
  • getzfsvfs busies the filesystem (and drops the reference from getzfsvfs_impl)

Also, zfs_unmount_snap() now gets a busied a filesystem, references it
and then unbusies it essentially reverting actions done in getzfsvfs.
This is needed because the code may perform some checks that require the
zfsvfs_t. So, those are done before the unbusying.

MFC after: 2 weeks

Details

Provenance
avgAuthored on
Parents
rS329822: Add bsdlabel and fdisk to powerpc64
Branches
Unknown
Tags
Unknown