[SOLVED] Possible to set a sd address offset for usb drives?

[Meow]

I made a bad mistake when setting up my zfs pool, used sd? instead of wwn-... for the zfs drives.

Now I found I have the problem that every time when I boot with some thumb drive plugged in, the thumb drive gets allocated a sd? number inbetween the sd? spinning drives.
This in turn makes the zfs volume mount fail at boot.

Is there a way to define that thumb drives get allocated at a particular offset, say, sdi, or, sdp so that they will not clobber the sd sequence for the spinning drives?
Or, at least a way to make the thumb drives getting assigned letters past the last spinning drive?

Thank you.

[Meow]

This seems possible with udev rules.
Here is a post giving hints how it could look: https://stackoverflow.com/questions/184 ... th-dev-sdb

And there is an old howto, which could help also to achieve this: https://wiki.debian.org/Persistent_disk_names
Will have to read around a bit how to write an udev configuration to set this up with current Debian and post the result.

If somebody knows more resources about this topic or even a ready-to-use example configuration, I'd appreciate if links could be posted.

[bw123]

It probably is possible to RE-define the assigned /dev/sdX name, but it might not be necessary to solve your problem. It could also create other problems.? The way I understand it, different bios can supply the different bootable devices in a different order, depending on type of interface(ide, sata,scsi,usb) so it was decided at some point to use scsi emulation for them all.

http://www.tldp.org/HOWTO/Partition-Mas ... O/x99.html

[p.H]

I made a bad mistake when setting up my zfs pool, used sd? instead of wwn-... for the zfs drives.

What do you mean exactly ? Do /dev/sd* names appear in some config files ?

A feature of modern GNU/Linux systems is that disk block device numbering and naming is not persistent by design, and IMO should not be expected to be. So you should fix your ZFS setup so that it uses any persistent identifiers instead of /dev/sd* names.

The way I understand it, different bios can supply the different bootable devices in a different order, depending on type of interface(ide, sata,scsi,usb) so it was decided at some point to use scsi emulation for them all.

You understand wrong. SCSI emulation has nothing to do with the BIOS.

[bw123]

The way I understand it, different bios can supply the different bootable devices in a different order, depending on type of interface(ide, sata,scsi,usb) so it was decided at some point to use scsi emulation for them all.

You understand wrong. SCSI emulation has nothing to do with the BIOS.

It's one of my many faults to misunderstand things. The word "so" should probably be a comma or a period. I can't provide any documentation for why on the same system my ide, sata, and usb drives all show up as scsi or why their block names change. I haven't been able to understand whether it is bios, kernel, udev, or a combination of all three that is responsible...

[p.H]

You correctly understood they all show up as SCSI drives because of the SCSI emulation layer.
This is purely a kernel thing. Although the underlying hardware protocols and command sets are different, USB mass storage drivers and current PATA/SATA libata-based drivers expose USB and ATA drives as SCSI drives to the other kernel subsystems and the userland. I guess the goal was to unify the way to communicate with any drive type. Why SCSI ? Well, I guess that it is because it has the richest feature set of the three.

Now, why are the device names of SCSI devices not persistent ? It is due to several factors :
- most kernel drivers are modules which are loaded asynchronously ;
- kernel drivers probe devices in parallel ;
- SCSI drive device names are assigned in the order the devices are discovered by the kernel. The drive discovered first gets sda, then the next one gets sdb and so on.

When you combine these factors, the result is dependent to tiny time variations.

Udev plays only a little role by default : when it is notified that the kernel discovered a new device, it invokes modprobe to load the proper kernel driver modules. With other types of devices, it may play major role ; for instance it is responsible for rename network interfaces according to a persistent or predictable naming scheme.

The older IDE drivers (IDE is actually the same as PATA, but in the kernel it refers to the older drivers while PATA refers to the current libata-based drivers) gave fixed names based on the physical position : hda was the master drive on the primary channel of the first controller... hdd was the slave drive on the secondary channel of the first controller.

Note that USB drives get a 1 second penalty by default, so most often they are discovered later than other drives and do not get the first device names. This delay can be changed with the "delay_use" parameter of the "usb-storage" kernel module.

[Meow]

I made a bad mistake when setting up my zfs pool, used sd? instead of wwn-... for the zfs drives.

What do you mean exactly ? Do /dev/sd* names appear in some config files ?

No... that is handled by ZoL. I guess it possibly used the /dev/sdX identifiers in the ZFS disk identification structure instead of the WWN and that might have caused the pool not be mounted at boot time.
(Background is that FreeBSD has no WWN, and I just created the pool using the zpool ... create raidzX /dev/... ... ... I was used to, instead of specifying /dev/disk/by-id/wwn-..., because ZFS normally uses the WWN for identifying drives by itself)
I guess I should investigate this and post an issue with ZoL if this proves true.

While I was reading through the documentations on udev and its rulewriting, I found udev has become useless for setting device node names, because of some recent systemd change that now only allows network device node names to be set. The Debian man page is correct in this, but there is many older documentation which still states that one could use that, which confused me.
It would have been useless anyway because of kernel setting minor device numbers

Note that USB drives get a 1 second penalty by default, so most often they are discovered later than other drives and do not get the first device names. This delay can be changed with the "delay_use" parameter of the "usb-storage" kernel module.

This will solve my problem of the sas drives' order being clobbered by usb drives at boot time.
I guess echo '15' > /sys/module/usb_storage/parameters/delay_use will be sufficient.

Thank you very much!

[p.H]

I guess echo '15' > /sys/module/usb_storage/parameters/delay_use will be sufficient.

Err... this is not persistent so you would have to do this very early if you want it to be effective at boot time.
I think is would be simpler to pass the parameter in the kernel command line with GRUB.

[Meow]

Oops, yes...
Still new to the new grubby systemd world

I now added "usb-storage.delay_use=15" to the GRUB_CMDLINE_LINUX_DEFAULT entry in /etc/default/grub and re-ran grub-install.

Thank you for reminding me!