[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