How does the kernel decide what device to create when a new drive is plugged in?
 

I have 1 permanent drive. I often plug in a USB drive. Usually it's assigned /dev/sdb . Sometimes it's assigned /dev/sdc even though sdb is available. Why? I have scripts that expect /dev/sdb.

sda, sdb, sdc and so on are not persistent names. I can't tell you what causes your particular disk to be sometimes sdb, sometimes sdc, but in any case it's risky (as you just learned :)) to believe that the disk will always get the same device name.

Your disk has various properties that your system uses to generate persistent names, such as UUIDs, filesystem or swap LABELs, hardware paths, SCSI addresses and so on. In most distros, udev creates symbolic links under /dev/disk whose names are guaranteed to always refer to the same disk.

(not quite actually - when you clone a disk, the clone will receive all UUIDs and LABELs, and you can connect the same disk to different hardware paths. As long as you know what you are doing, though, the persistent naming mechanisms work reliably)

Since I don't know your application, I don't have a full solution for your problem, but I suggest to educate yourself about persistent naming.

you might see a switch from sdb to sdc if the status of the drive changed in some way.

You should not use scripts that require sda sdb etc.
What if you have 2 usb drives , how does your script know you plugged the right one in?

hint:
[code]
ls -l /dev/disk/*
]/code]

/dev/disk/by-uuid
Is probably what you want
But I have no idea what you have scripted, so that is a complete guess.

for something your script can work with

following the comments above...I get around this by creating a mount point and adding an entry to /etc/fstab with the mount point and the UUID of the drive. I use the mount point in my scripts. If the USB drive changes, change fstab to recognise this

The fact that my learned friends have not already mentioned this makes me wonder...am I missing the point

no idea what the script is doing
maybe it is putting a fs on the partition.


all we know is some script needs /dev/sdb

Which tells me said script needs to be re-written or at least fixed.

I've experienced this. I think it has something to do with timing. If sdb is available, it will always be assigned sdb. In some cases sdb WAS assigned (and probably not properly unmounted), then next time (shortly after) it was assigned sdc instead of sdb although sdb appeared to be available.

I don't know the root cause, but I can confirm the "issue". And personally I think it has something to do with inproper unmount of a device and device timeout.

This is good advice regarding the script part.

Absolutely. For example, what if there is no file system on the disk? Or not even a UUID?

Duh.

That's an argument never to ask any question.

Then I know that and act appropriately.


Turns out not to be the case.


Good idea. I hadn't thought of this. Unfortunately it requires an entry for every device, more of an inconvenience than I have now.

It already works. I was just curious about what is persisting in the mind of the kernel that keeps /dev/sdb unavailable.

What if a fire has broken out?

I don't have a problem, but a question.

Your script doesn't work, the reason you started the thread proves that.
Edit: "is broken" is a better fit than "doesn't work"


if you are going to troll, at least be smart about it.

Then sdb is still not viable, and UUIDs only work for a subset of all disks, and mounts for a subset of that.

There's /dev/disk/by-id/, which contains entries that include the drive's model and serial number, e.g.:That's assuming you have the needed udev rules in place to set up those entries, of course.

No it doesn't. My script works. Sometimes it finds /dev/sdb unavailable even though it doesn't exist. It tries /dev/sdc next.

Both your phrases; I used neither.

It turned out to be an orphaned entry in /etc/mtab.

not something you said in the OP

If you want to carry on using error prone, flaky scripts on your slackware
It won't make too much difference.

If the behaviour of sdx is predictable, then there should not be an issue in writing such a script. sdx SHOULD be predictable if you use it to be predictable, and thus the script SHOULD work.

The issue here is the behavious of sdx IS NOT predictable despite using sdx in a way that it SHOULD be predictable. The question is why. I added my view and have experienced the same behaviour, and I think the conclusion of the thread is pretty much the same with "the orphan in /etc/mtab".

The more important question is, why does that happen?

My theory had to do with inproper unmount and timeout. After x time, you will be assigned sdb in either case, but factor y causes sdc "issue" before x time factor, due to cause z.

Is cause z inproper unmount? I don't know. Is there an x timeout factor? I'm not sure. z=y?

I don't know what the script does

it should not expect /dev/sdb since you can not guarantee that will exist or that it will be correct.

see the OP !

The Script should either, rely on user input when running the script
or, the UUID ( the Filesystem ) / PARTUUID ( the specific drives partition )