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.
Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
[SOLVED] Possible to set a sd address offset for usb drives?
Re: Possible to define a sd? address offset for thumb drives
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.
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.
Re: Possible to define a sd? address offset for thumb drives
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
http://www.tldp.org/HOWTO/Partition-Mas ... O/x99.html
resigned by AI ChatGPT
-
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 132 times
Re: Possible to define a sd? address offset for thumb drives
What do you mean exactly ? Do /dev/sd* names appear in some config files ?Meow wrote:I made a bad mistake when setting up my zfs pool, used sd? instead of wwn-... for the zfs drives.
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.
You understand wrong. SCSI emulation has nothing to do with the BIOS.bw123 wrote: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.
Re: Possible to define a sd? address offset for thumb drives
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 wrote:bw123 wrote: 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.
resigned by AI ChatGPT
-
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 132 times
Re: Possible to define a sd? address offset for thumb drives
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.
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.
Re: Possible to define a sd? address offset for thumb drives
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.p.H wrote:What do you mean exactly ? Do /dev/sd* names appear in some config files ?Meow wrote:I made a bad mistake when setting up my zfs pool, used sd? instead of wwn-... for the zfs drives.
(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
This will solve my problem of the sas drives' order being clobbered by usb drives at boot time.p.H wrote: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.
I guess echo '15' > /sys/module/usb_storage/parameters/delay_use will be sufficient.
Thank you very much!
-
- Global Moderator
- Posts: 3049
- Joined: 2017-09-17 07:12
- Has thanked: 5 times
- Been thanked: 132 times
Re: [SOLVED] Possible to set a sd address offset for usb dri
Err... this is not persistent so you would have to do this very early if you want it to be effective at boot time.Meow wrote:I guess echo '15' > /sys/module/usb_storage/parameters/delay_use will be sufficient.
I think is would be simpler to pass the parameter in the kernel command line with GRUB.
Re: [SOLVED] Possible to set a sd address offset for usb dri
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!
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!