[zfs-discuss] Failed to Import Pool via Cache File

Chris Siebenmann cks at cs.toronto.edu
Tue Dec 19 15:17:24 EST 2017

> My point isn't that zfs should scan for any pool it can find but
> that there should be a /text/ configration file (left alone by ZFS)
> containing a list of pools to import (and mount) in the given order.
> With zpool.cache being a /binary /file that is /magically /updated (by
> zpool import/export invocations) with the set of pools to import it
> dosn't look like good unix style to me.

 One of the complications here is that ZFS does not actually import
pools on boot, in the sense that it does not go through a process of
doing 'zpool import <pool>' for each pool. Instead, there is a magic
procedure where information from zpool.cache is loaded into the kernel
and used to create half-alive pools, which are then activated and
finalized when further things run that need them to be fully alive (such
as 'zpool mount -a'). This process bypasses a certain amount of work
that the real 'zpool import' does, which is why it falls over if the
device names change.

(Similarly, I believe that pools are not exported even on an orderly
shutdown, in the sense of 'zpool export'.)

 Duplicating this process with more explicit and less magical support is
not simply a matter of changing the user-side ZFS tools so they read a
pool list from a text file; it also requires a number of kernel changes
and likely updates to the internal user/kernel interface for setting up

 I certainly would like less magic here. But I don't expect it to happen
any time soon, especially as it would probably create real divergence
between ZFS on Linux and the upstream ZFS code, unless the other systems
involved could be persuaded to move in the same direction.

(As for how the root pool works with this magic, unfortunately I have no
idea. I never dug into the kernel code deeply enough to understand that
extra layer of magic.)

	- cks

More information about the zfs-discuss mailing list