I think you do not understand the implications that changing this would have.
This has been like that forever and, at the end of the day, both are drives and are usually used similarly by the processes in the system.

Pros:
- Make it a little bit easier for programmers and users to know which one is which, even though this is usually not needed.

Cons:
- Literally *destroying* everything that has already been made for basically no real reason.

Hi Javier,

Thanks for taking this up.

Your statement of pros and cons is precise.

Is it still possible for Linux to extend the option to the user (maybe a kernel argument passed in via the Grub commandline) to have USB mass storage devices enumerated in a different nomenclature series ? If that is possible, we can take up all the pros of the solution with none of the cons of the situation.

This message is also being emailed to javier@beren.dev


Regards,
Manish Jain

Yes, it would be possible, but I think that we have all heard what Linus says (or rather, shouts) when we try to modify these parts of the code. Also, I do not think this is a bug, and I am completely sure that it is not a P1 high importance bug. Maybe this is a change that could be proposed, but I am not sure that this is the right forum.

Could you be kind enough to propose the change yourself ? Personally, I would have liked to propose the change myself, but I am virtually a nobody in the Linux world.


Thanks,
Manish Jain

Plus you can close out this bug report as Fixed if you wish. Thanks again.

I think I have not made this clear, I am not part of the official support team, because there just isn't one. You have the ability to propose the change as much as me. Also, you will have to close this thread yourself.

The original premise of the bug description is wrong.

Firstly, the "sd*" moniker does not refer to the type of drive.  Rather, it refers to which kernel driver is managing the drive.  Both SCSI disks and USB disks use the SCSI sd driver; hence they should share the same moniker.

Secondly, the mere fact that the names are similar doesn't make it impossible to distinguish one type of transport from the other.  The information is readily available in sysfs.

Thirdly, Manish seems to think there's some important difference between SATA disk drives and USB disk drives.  That's not so; in fact, many USB drives actually are SATA drives attached via a USB-SATA adapter.

Hi Allan,

Thanks for tuning in.

The following has happened to me a couple of times, and the only way a third occurrence could be avoided is if USB mass storage devices nodes use a different nomenclature series vis-a-vis SATA disks.

Here is the incident:

I installed Linux using a memstick (USB pen drive), which got enumerated as sda while my internal hard disk got enumerated as sdb. When installation finished, my system was ready for reboot - except that I was not aware that my hard disk will next time appear as sda, not sdb as was the case during installation. So my fstab was all a mess, and it took me hours to figure out why my Linux was failing to boot. The only way I could correct the situation was to boot into FreeBSD and set up my Linux fstab correctly.

Now as for your assertion "many USB drives actually are SATA drives attached via a USB-SATA adapter". It could not be more true. I have an internal SATA SSD myself that I occasionally attach to my system as an external USB device using a USB-SATA adapter. The right thing for Linux to do is allocate the device node for the SSD depending on the interface via which it was plugged in. Meaning, if it was plugged in as an internal SATA disk, it will acquire the moniker sd*. But if it is plugged in via the USB interface, it should get the moniker ud* (or anything different from sd*).

I hope I have made my case clearly enough.

Thank you,
Manish Jain

(I bet you could have fixed the fstab contents by booting from the pen drive in "rescue" mode, with no need to have FreeBSD installed.)

Changing the monikers is only a partial solution.  For example, devices that show up as uda and udb one day could very well show up as udb and uda the next day.

Also, suppose your system's primary hard disk was attached by USB rather than SATA.  Then the pen drive could have been labelled uda and the primary drive labelled udb, and your fstab would still be messed up.  This is part of the reason why people recommend using filesystem or GUID labels for fstab entries rather than drive names and partition numbers.

In short, changing the monikers isn't going to happen, and even if it did happen it wouldn't fully fix your original problem.

However, there is a way to set up your system to use permanently fixed drive names that you assign.  All you have to do is write and install an appropriate udev script.  Then you can make the drive names be anything you want.

Hi Allan,

Although I am pretty much resigned that the change I am requesting won't happen, our discussion certainly keeps getting more interesting - particularly if you are willing to accept the possibility that each of your statements in the previous message was incorrect.

Here are your statements:

1) "Changing the monikers is only a partial solution.  For example, devices that show up as uda and udb one day could very well show up as udb and uda the next day." I have been using my computer for I don't remember how many years, but it has never happened even once that I needed to simultaneously attach two USB mass storage devices. In other words, you don't have to worry about udb - there will usually only be a uda in the ud* series.

2) "Also, suppose your system's primary hard disk was attached by USB rather than SATA.  Then the pen drive could have been labelled uda and the primary drive labelled udb, and your fstab would still be messed up.  This is part of the reason why people recommend using filesystem or GUID labels for fstab entries rather than drive names and partition numbers." a) We should perhaps restrict ourselves to the the real world where people want their primary hard disk to never be attached by USB. The primary hard disk will always be attached via SATA/NVME. The SSD that I attach to my system via USB is not my primary hard disk and never will be - it is my backup device to which I perform my daily rsync. b) I find using UUIDs to be a bad idea, perhaps even abhorrent. I strongly prefer my fstab and grub configuration wired for device nodes, so that when I need to fsck, I clearly remember which device nodes to fsck. There is another use-case - folks might want a triple-boot computer with Windows 10 + Linux + FreeBSD with Windows 10 somewhere outside the first primary disk. That, as it happens, is only possible by disabling UUIDs in Linux's fstab/grub. I am emailing to you my document on how to set up such a computer. Once you have read the document, you will probably realize that such use cases might exist where UUID usage was strongly undesirable.

3) "In short, changing the monikers isn't going to happen, and even if it did happen it wouldn't fully fix your original problem." My bad luck if the monikers cannot be changed. But the change WOULD fully fix my original problem, I humbly assure you.

4) "However, there is a way to set up your system to use permanently fixed drive names that you assign.  All you have to do is write and install an appropriate udev script. Then you can make the drive names be anything you want." This is a post-install procedure. The moniker fix will solve the problem when it occurs at Linux installation time.

All right.  I don't have much time to spend on this, so I'll keep it brief.

Your point of view is too narrow.  As a maintainer, one quickly learns that any change made to the kernel will affect _all_ users, not just the person who requested the change.

You ran into a problem in one single situation (a new OS installation).  You came up with an ad-hoc way to prevent the problem from occurring, but you didn't think that your solution would _cause_ problems for many other people, who rely (or have software that relies) on the current naming scheme.

Furthermore, it's a mistake to think that Linux runs only on desktop systems.  In fact it gets used in everything from giant supercomputers to servers to tablets to hobby boards to IoT devices to wearables.  Just because you have never used a USB drive as the primary disk or attached two USB drives simultaneously to your system doesn't mean nobody else has.

(In fact, one of my servers does have two USB drives attached.  They are used for rotating backups.)

Furthermore, when presented with a well-known and commonly accepted technique for avoiding the problem you encountered (using filesystem labels or GUID labels), you rejected it.  If you don't want to use these things yourself, that's fine -- but you shouldn't expect everyone else in the world to change the naming conventions on their systems to suit your preference.

(In your triple-boot document, GUIDs would work perfectly well for everything except the swap partition, because Windows would overwrite it.  But lack of a swap partition wouldn't prevent you from booting.)

Hi Alan,

I request one more reasoning session. I would like to present an argument. If the argument does not convince you, I shall close this thread for all times.

The argument is:

Consider yourself a cannabis user. Cannabis is legal in most countries now (at least for medical use). An estimated 15% of Europe and America uses cannabis.

While high on pot, you suddenly remember something on your USB pen drive needs to be accessed immediately.

You attach the USB pen drive, and try to mount it.

If USB disks use the ud* series, your command becomes:

mount -t /dev/ud<TAB>

If USB disks use the sd* series, your command becomes:

mount -t /dev/sdb<TAB>

Which one would you prefer ?


Thanks,
Manish Jain

That should have been:

mount /dev/ud<TAB>
mount /dev/sdb<TAB>


Sorry for the typo.

You're not serious, are you?

In case you are, I'll point out that with the ud* naming scheme you would actually have to type:

mount /dev/uda<TAB>

I don't find this particularly better or worse than

mount /dev/sdb<TAB>

but it would be one more thing to remember, so worse in that respect.  Not to mention that it would mean changing all the existing shell scripts and /etc/fstab files that already use the /dev/sdb* names.

Hi Alan,

Nice to see your response to the reopened PR.

1)
'mount /dev/uda<TAB>' : I think you are missing the point about USB disk attachments. As I said earlier, there usually there will usually be only one of those (I never had to attach 2 pen drives simultaneously). So there will usually be only a /dev/uda in the ud* - or else nothing in the ud* series.

So you can start tabbing at 'd' : mount /dev/ud<TAB>.

So that definitely provides the adavantage of 1 character less to type at a time when you want to type less.

2)
'it would be one more thing to remember, so worse in that respect'. Sir, my humble intuition is this would be an advantage. So many changes (eth0 -> enp9s0) happen with no real benefit to the end user. This one has an advantage: one character less to type, plus the comfort of the knowledge that USB have their own series. People will welcome this change, if it were permitted to happen.

3)
'it would mean changing all the existing shell scripts and /etc/fstab files that already use the /dev/sdb* names' :

find . -type f -name '*.sh' -exec sed 's/sdb/uda/g' {} \;;

Thanks again for your response.
Manish Jain

"This one has an advantage: one character less to type, plus the comfort of the knowledge that USB have their own series"

was meant to be:

"This one has an advantage: one character less to type, plus the comfort of the knowledge that USB mass storage devices have their own series"

Sorry for the typo.

This is not going to change, sorry.

We can not rename USB block device names, as it would break all current systems that have been working just fine for the past 20+ years with USB disks on Linux.  To do so is crazy and not how Linux development works at all.

If we were to do this, there would be hundreds of thousands of mad users and broken systems, not something that you should be asking to have happen.

If you want persistent disk names, use /dev/disk/by-*/ symlinks, that is what they are there for, and have been there for 15+ years.

(In reply to Manish Jain from comment #15)
> Hi Alan,
> 
> Nice to see your response to the reopened PR.

Storage and UAS do use the SCSI command set. Hence

1) the commands specific to SCSI can be issued
2) there is an sg device associated with each sd
3) we have optical drives, tapes and other devices on USB (USB-SCSI bridges are real)

Hence if anything is inappropriately named, it would be SATA devices, not USB devices.