[Pkg-zfsonlinux-devel] Bug#940678: Please import pools by stable device label

[Antonio Russo]

On 9/29/19 2:30 PM, Alberto Berti wrote:
> Hi Antonio,
> 
> thanks for answering.

No problem! :-)

> 
>>>>>> "Antonio" == Antonio Russo <antonio.e.russo at gmail.com> writes:
> 
>     Antonio> Could you please clarify: did you experience any data loss,
>     Antonio> or were you simply unable to import your pool at one point?
> 
> The pool systematically fails to mount after the upgrade, at each boot,
> even if I manually mounted it.. 

The terminology with ZFS is a little different: pools are "imported"
and the datasets (that are filesystems rather than, say, zvols) are then
"mounted".  It sounds like you cannot import the pool, and therefore you
cannot mount the datasets.

Is your problem reproducible? By that I mean, on reboot, does the pool
import or not?

And what do you mean by "manually mounted it"? Are you talking about

# zpool import -d /dev -aN

If it's not mounting on reboot, just use -d /dev/disk/by-id next time,
and the problem should go away.

> this leads to data loss from a user pow, because the data that's not> there may get re-written and generate conflicts.
If another application does not gracefully handle missing data, by all
means that is a bug for that application. That's not, however, a ZFS
bug.

I would encourage you to open a separate bug, unrelated to this, for
that issue.

> 
>     Antonio> As a second note, you should have done something like
> 
>     Antonio> zpool import -d /dev/disks/by-id -a
> 
>     Antonio> so that your import is done by labels that are stable
>     Antonio> across boots (names like /dev/sdX are not necessarily
>     Antonio> stable). This is a "well-known" best practice with ZFS [1]
>     Antonio> (you should always create pools using these symlinks as
>     Antonio> well).
> 
> good to know, thanks. Although I think that if the hardware
> configuration nor the kernel version changes between the boots, we can
> assume that each block device will get the same id... anyway I'll try it.

First off, there's typo. Use /dev/disk/by-id . Not with an extra s.

You can check this---note which device nodes are being linked by the
stable identifiers in /dev/disk/by-id. Do they change on reboot?

If you find that your device nodes are to exactly the same drives, and
yet the pool is not importing as you have found, that's definitely a bug,
and we'll have to file it upstream. You will need verbatim dmesg logs,
the zpool status $poolname output, and the output of ls -l /dev/disk/by-id
on subsequent boots.

Upstream will want to see exactly what is going on with the device nodes,
since that's the most likely cause of this problem.

> 
>     Antonio> If you have only experienced an inability to import your
>     Antonio> pool at boot, my guess is that you had (and continue to
>     Antonio> have) the inappropriate import by device node setup. This
>     Antonio> configuration error will lead to you continuing to have
>     Antonio> problems importing your pool at later times, and is not a
>     Antonio> bug. To fix that problem you should zpool export all your
>     Antonio> pools (this might be tricky, especially if you are zfs on
>     Antonio> root), and then run the above command. As always, double
>     Antonio> check all this!
> 
> uhumm, Yes, that is tricky, as I read that the export operation unmounts
> every exported fs before the operation.

Yes, to export a pool, none of its datasets can be in use (e.g., mounted).
Be careful with the terminology here---exporting a filesystem (or dataset)
means something totally different than exporting a pool.

> 
> So you say that if I do that the start of the zfs-import-cache in the
> next boot will succeed?

Barring a new bug, yes.

> 
> thank you
> 
> Alberto
> 

Best,
Antonio