#2254 Issue closed: ReaR must work independent of kernel device names¶
Labels: enhancement, cleanup, severe improvement
jsmeix opened issue at 2019-10-17 12:34:¶
On an internal SUSE mailing list I learned about the following
change in the kernel:
https://marc.info/?l=linux-kernel&m=157013477505405&w=2
that reads (excerpts)
Beginning with kernel 5.3 the order in which SCSI devices
are probed and named has become non-deterministic.
This is a result of a patch that was submitted to add
asynchronous device probing (specifically, commit
f049cf1a7b6737c75884247c3f6383ef104d255a).
Previously, devices would always be probed in the order
in which they exist on the bus, resulting in the first device
being named 'sda', the second device 'sdb', and so on.
An explanation what that is
(except from an SUSE internal mail - a bit modified by me here):
Controllers could be probed in parallel
but the devices would still appear in the same order
on a per-controller basis.
If there was only one controller, they'd be predictable
as long as new devices weren't added in the middle.
Now the probing happens asynchronously on a per-device basis,
so even devices on a single bus can appear in "random" order.
The only stable configuration now is one with a single disk.
That's a change in behavior that,
even though ... documented as unpredictable,
has been very much predictable for years.
This means when before /dev/sda and /dev/sdb were
on the same controller (or bus) their naming was stable
but beginning with kernel 5.3 their naming is random.
Because in general kenel device names are unstable
since a long time, ReaR must get rid of using kenel device names
in particular in disklayout.conf and use better methods instead.
jsmeix commented at 2019-10-17 12:40:¶
I think it becomes more and more a need
to completely overhaul the whole disk layout recreation code
to make it sufficiently up to date and ideally more future proof,
cf.
https://github.com/rear/rear/issues/1390
and
https://github.com/rear/rear/issues/791#issuecomment-406513969
BUT
https://github.com/rear/rear/issues/799#issuecomment-531247109
jsmeix commented at 2019-10-23 15:41:¶
Something related:
It seems
https://github.com/rear/rear/issues/1958
is at least somehow related because in general
it should not matter which of the possible names
for one same block device is used.
E.g. on my workstation I have 9 additional (alias/link) names
for my root partition /dev/sda2
# lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT /dev/sda
NAME KNAME PKNAME TRAN TYPE FSTYPE SIZE MOUNTPOINT
/dev/sda /dev/sda sata disk 931.5G
|-/dev/sda1 /dev/sda1 /dev/sda part vfat 500M /boot/efi
|-/dev/sda2 /dev/sda2 /dev/sda part ext4 915.5G /
`-/dev/sda3 /dev/sda3 /dev/sda part swap 15.6G [SWAP]
# find /dev/disk/by-* -ls | grep -o '/dev/disk/by-.*/sda2'
/dev/disk/by-id/wwn-0x50014ee2b71cd724-part2 -> ../../sda2
/dev/disk/by-id/scsi-SATA_WDC_WD10EZEX-75M_WD-WCC3F1AEYTNS-part2 -> ../../sda2
/dev/disk/by-id/scsi-350014ee2b71cd724-part2 -> ../../sda2
/dev/disk/by-id/scsi-1ATA_WDC_WD10EZEX-75M2NA0_WD-WCC3F1AEYTNS-part2 -> ../../sda2
/dev/disk/by-id/scsi-0ATA_WDC_WD10EZEX-75M_WD-WCC3F1AEYTNS-part2 -> ../../sda2
/dev/disk/by-id/ata-WDC_WD10EZEX-75M2NA0_WD-WCC3F1AEYTNS-part2 -> ../../sda2
/dev/disk/by-partuuid/a55fd91f-6714-47a4-983a-e7b6f50fb9aa -> ../../sda2
/dev/disk/by-path/pci-0000:00:1f.2-ata-1-part2 -> ../../sda2
/dev/disk/by-uuid/aed8d81b-29bf-405e-9049-29a6c0e702d3 -> ../../sda2
Ideally it should be possible to use anywhere any of the names
/dev/sda2
/dev/disk/by-id/wwn-0x50014ee2b71cd724-part2
/dev/disk/by-id/scsi-SATA_WDC_WD10EZEX-75M_WD-WCC3F1AEYTNS-part2
/dev/disk/by-id/scsi-350014ee2b71cd724-part2
/dev/disk/by-id/scsi-1ATA_WDC_WD10EZEX-75M2NA0_WD-WCC3F1AEYTNS-part2
/dev/disk/by-id/scsi-0ATA_WDC_WD10EZEX-75M_WD-WCC3F1AEYTNS-part2
/dev/disk/by-id/ata-WDC_WD10EZEX-75M2NA0_WD-WCC3F1AEYTNS-part2
/dev/disk/by-partuuid/a55fd91f-6714-47a4-983a-e7b6f50fb9aa
/dev/disk/by-path/pci-0000:00:1f.2-ata-1-part2
/dev/disk/by-uuid/aed8d81b-29bf-405e-9049-29a6c0e702d3
and things should "just work".
So an immediate offhanded (and totally untested) idea is
to implement a generic function named something like
get_kernel_block_device_name()
that outputs the kernel block device name (/dev/sda2 in the above
example)
for any of its existing names, e.g.
get_kernel_block_device_name /dev/disk/by-path/pci-0000:00:1f.2-ata-1-part2
would output /dev/sda2 and in particular
get_kernel_block_device_name /dev/sda2
would also output /dev/sda2.
So the idea behind is to still use the kernel block device name
as the ultimate value that is finally used when calling commands
because the kernel block device name is the only one that must exist
but it should not matter when another compatible name for that thingy
is used elsewhere for example in config files.
jsmeix commented at 2020-02-10 13:40:¶
My SUSE Hack Week 19 project is
https://hackweek.suse.com/19/projects/relax-and-recover-rear-proof-of-concept-implementation-of-new-storage-code
jsmeix commented at 2020-03-06 09:22:¶
FYI:
Since SUSE Hack Week 19 I am experimenting with that things in
https://github.com/jsmeix/rear/tree/new_storare_initial_experimental_playground_issue2254
github-actions commented at 2020-06-26 01:39:¶
Stale issue message
[Export of Github issue for rear/rear.]