Short answer ... Hit any of the countless udev howtos on how to lock down devices to specific device names, with specific permissions, etc... Otherwise, just rely on the UUIDs of the filesystems, and ignore the device assignments. Long answer ... First off, reassignment of devices happens in _all_ OSes. This is hardly a Linux phenomenon. I have no idea what your intent is here (other than what I shall not say). Secondly, because reassignment is such an issue, Fedora, Ubuntu and countless other distros have switched to UUIDs for filesystem identification. UUIDs are unique. This also caused a lot of blame and demonizations when people started seeing UUIDs in /etc/fstab as well, without stopping to understand why this very necessary decision was finally made. Third, the udev system allows one to tie down device names to specific hardware using hardware IDs and other details. Indeed, this is how I often deal with SAN and other devices. It's also where multipathing ties into as well. And at home, I also use udev rules to assign devices for my removable USB devices. If you absolutely want to ensure specific naming, permissions, etc... with a device, use udev. If you don't need to, then just rely on UUIDs. Fourth, the decision was made long ago to unify most read/ write block device names as "sdX" devices and most read-only block devices as "sr0" devices. The "SCSI" name is largely a left-over. There are countless devices that use the SCSI block system that do _not_ support SCSI protocols at all -- FireWire, USB, etc... So don't assign any attachment to the term "SCSI." It also unified the labeling/ID as well, making things far, far more consistent than prior. Other OSes do this as well (NT comes to mind too, along with several UNIX flavors). SCSI is just a read/write block interface, whether dumb block or one with a more intelligent command-set like SCSI-2, FireWire, etc... Lastly, the "old schemes" are fine when you have limited device support. But today, modern Linux has countless support of an extremely broad range of devices. The "old schemes" don't fit well, let alone are grossly inconsistent. The "new schemes" are much better, avoid device issues and other details. I wouldn't say this if I have not run into assignment and other details under all OSes. Newer approaches in Linux 2.6-based distro do a far better job now. One either chooses to move forward or one only exposes that they have not -- let alone has not taking the time why the changes were made and should move forward. ;) ----- Original Message ---- From: Alan Grimes <agrimes@xxxxxxxxxxxxx> To: linux-hotplug@xxxxxxxxxxxxxxx; Northern Virginia Linux User's Group <novalug@xxxxxxxxxxxxxxx> Cc: Scott D'Vileskis <sdvileskis@xxxxxxxxxxx> Sent: Thu, March 11, 2010 10:37:13 AM Subject: [Novalug] Device naming. Due to the lack of documentation on the subject, I have been forced to do my own investigation and make my own conclusions regarding recent changes to the naming of devices on linux. My verdict is that it's the latest example in a chain of spectacularly bad design decisions made by linux developers (Penguins) in the past year or two. Here's why. The purpose of the /dev path is to allow administrators to access devices attached to their systems. Therefore it is sensible for each device handle to expose to the administrator essential facts such as what type of device it is, which controller it is attached to, the position number on that controller and, finally, the identifier of any virtual devices which might benefit from being treated separately. Furthermore the administrator doesn't have the slightest interest in what driver is behind the device, that is irrelevant information that should be hidden. Minix, IIRC did this correctly. Each name has a very easy to understand encoding. The old scheme on Linux did an adequate job of this too. The first two letters indicated what technology it was, the third letter was a mix of controller and position information, and the number indicated the virtual device being referenced. I did an experiment the other day which involved plugging a USB thumb drive into the server. To my horror, the operating system assigned it /dev/sda. The Penguins had gone and *intentionally* designed a namespace collision between all possible storage solutions that might be attached to the computer!!! This is insane. How do I know what drives are which when I go to write an /etc/fstab? If I make any changes to the controllers in the system, designations of existing drives are sure to change. =\ I am aware of /dev/disk so don't flame me about THAT, I have examined it closely and have not found any way to make use of it because it is not possible to reliably predict how a new drive would appear there. On my existing system that is still running an old linux kernel, the device ID of my boot drive is: ata-ST380013A_5JVA01L2 Which is correct... But the device id of my data drive is: scsi-SATA_WDC_WD3200AAKS-_WD-WCAT11129455 Which is wrong because I don't own any SCSI hardware. It should be: SATA-WDC_WD3200AAKS-_WD-WCAT11129455 WTF??? My data drive has two entries in there, the other is: ata-WDC_WD3200AAKS-00B3A0_WD-WCAT11129455 Which is not that inaccurate because SATA is a form of ATA, however it is useful to be able to distinguish the two so you know where your new drive will appear. -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
