ZFS on Linux is improving the handling of disk names on import
Back in 2017 I wrote up how ZFS on Linux names disks in ZFS pools. One of the important parts of this is that ZFS on Linux only stored a single name for each disk (the full path to it), and if the path wasn't there when you tried to import the pool (including the import during boot using a cachefile), you had a problem. The good news is that ZFS on Linux (well, OpenZFS) has recently landed a change that significantly improves this situation.
To summarize what the change does (assuming I understand it correctly),
if an expected device in a pool is not found at the path for it in
the cachefile (which is the same as what the pool stores), ZoL will
attempt to search for all of the disks in the pool as if you were
running 'zpool import
'. This search has two restrictions; first,
it looks for the pool by GUID instead of by name (which is what
you'd expect), and second it only looks at devices in the same
directory or directories as the pool's original device names. So
if you specified all your devices by /dev/disk/by-path paths, the
import won't scan, say, /dev or /dev/disk/by-id. In the common case
this won't make a difference because all disks will be present in
all the /dev directories.
(Of course this assumes that udev is populating your /dev properly and promptly.)
It looks like this change will be in ZFS on Linux 2.1.0 when that gets released (and there was a release candidate just made recently for 2.1.0, so hopefully that won't be too far away). Interested parties can read the full commit message and description in commit 0936981d8. Based on reading the code, there seems to be no way to turn this off if for some reason you really want pool import to fail unless the disks are exactly where or what you expected. You can probably effectively disable it by setting up your own directory of symlinks to your pool's disks and then arranging for your pool to use that directory in all of its device names.
(I don't know if this change is even necessary in FreeBSD. If it is, presumably it will get there someday, but I have no idea how fast things move from OpenZFS to FreeBSD.)
|
|