One issue with unmounting the dataset prior to modifying the property is that it will be left unmounted if the dsl_dataset_set_fsid_guid_check() fails (for example if one tries to assign a fsid_guid that is already used).
Should I change the error message to warn the user ? ("fsid_guid is invalid or already in use, cannot remount file system")
Or only allow for the property to be set when the dataset is created, if that is an issue. (I don't think there is an easy way to check it from libzfs beforehand)
6333 ZFS should let the user specify or modify the fsid_guid of a dataset
Review Request #111 — Created Nov. 2, 2015 and updated
This is useful if you need to migrate NFS clients from a target system to another, without having to umount/remount all clients.
The fsid_guid is used to construct the vfs_fsid when mounting a dataset. vfs_fsid is then used as the fh3_fsid by NFS when sharing the dataset.
zfs create -o fsid_guid=xxx tank/test
zfs set fsid_guid=xxx tank/test
- that the property is reflected in the VFS ID when mounting the dataset.
- that migrating NFS client from a source system to another system on which the dataset fsid_guid matches the source dataset works without needing to remount clients (no "Stale NFS file handle" errors).
- that you cannot assign a fsid_guid identical to a dataset that is currently mounted. If you assign a dataset a fsid_guid identical to a currently unmounted dataset, the latter will be assigned a new fsid_guid upon being mounted. (as already happens in the case of a "real" collision. See existing comment at the beginning of dsl_dataset_sync() )
transferring comments from email to here.
zfs_create(): what error does lzc_create() if you try to create a
filesystem that already exists?
A. What if the dataset doesn't exist when zfs_dataset_exists() is called, and then another thread creates it before the lzc/ioctl is made?
B. The lzc_* interfaces should provide a good interface for all consumers, not just this one. If we use the same error code for 2 totally different types of error, it's hard to use.
I assume it's OK to not manipulate the unique avl because we know this is not mounted. Can you add an assertion to that effect?
Actually, even not being mounted is not strong enough. It will be in the avl tree if the dataset_t exists at all (see where we call unique_insert()). You might need to manipulate the AVL after all, unless you can ensure that the dataset_t doesn't exist.