Re: parent transid verify failed

[Eric Levy <contact@ericlevy.name>]

On Sun, 2022-01-02 at 00:57 -0500, Zygo Blaxell wrote:

> Device order (mapping of /dev/sd? device to underlying storage)
> usually
> isn't guaranteed, but once it's set it tends to be persistent;
> otherwise,
> disastrous problems would occur with every multi-device Linux
> subsystem:
> btrfs, mdadm, lvm, and dm-crypt would all significantly damage their
> data
> if the mapping from subdevice to physical storage changed
> unexpectedly
> while they were active.
> 
> In disconnect-reconnect cases, the old device is reconnected only if
> it
> can be reliably identified; otherwise, an entirely new device is
> created
> (as in the case where sdc became sdf after iSCSI logout and
> reconnect).

After poking around, I made an interesting discovery:

$ ls  -l /dev/disk/by-path
lrwxrwxrwx 1 root root  9 Jan  2 04:47 <iscsi-tgt-name>-lun-1 -> ../../sdd
lrwxrwxrwx 1 root root  9 Jan  2 04:47 <iscsi-tgt-name>-lun-2 -> ../../sdc

It seems somehow the devices are exposed to the system in a different
order from how they are scanned in the iSCSI session.

Although I hoped when I gave the rescan command to the iSCSI daemon, it
would simply add a device, actually it did much more.

Obviously, there should be better support for predictability and safety
in these procedures. It's rather unhelpful that even after rebooting,
the device order remains inverted in the two views.