[Pkg-zfsonlinux-devel] Comparing the Debian and Ubuntu version of spl-linux

Petter Reinholdtsen pere at hungry.com
Thu Sep 29 08:44:19 UTC 2016


[Turbo Fredriksson]
> If we don't feel like this is needed or if we have other ways to do the
> same task (which we do, although with a manual process), then maybe
> not use it in the first place?

After reading the discussion in #595790, it is clear to me that
gethostid() is a bad function to use on Linux to get a host specific ID
to store in the zfs pool.

So we should either find a different ID to use (for example
/etc/machine-id from systemd, /var/lib/dbus/machine-id from dbux or
/sys/devices/virtual/dmi/id/product_uuid on machines with DMI support),
or stop using a machine ID completely.  The latter should probably be
coordinated with upstream.

> The problem with the hostid is notoriously a problem when you boot
> from a ZFS system - you can't export a pool that's still in use, and
> if you boot from the pool, it will be in use up until the very second
> the CPU is restarted/rebooted.

Unless one pivot_root to a tmpfs during shutdown, to be able to release
the real root.  I'm not sure if that is possible with systemd or
sysvinit.  I guess LVM have the same problem.  How is the LVM volume
group released during shutdown?

> This means, that on the following boot, the pool will be marked as "in
> use", and will then refuse to import unless you ALWAYS force the
> import (which is a VERY bad idea in the long run).

Right.  Is there a way we can mark the pool read-only during shutdown,
or something similar that make it easier to accept it during boot?

> I've tried to mitigate that problem as much as possible in my
> initrd/sysv scripts, but I have been unable to remove it altogether.

How did you mitigate it?

-- 
Happy hacking
Petter Reinholdtsen



More information about the Pkg-zfsonlinux-devel mailing list