Oliver Neukum wrote: >>Consider a system with multiple removable ATA HDDs. If the bays connect >>to the host system via USB<->ATA bridges, the serial number that the >>host sees will be that of the bay, not the HDD itself. >> >Which is as it should be. > Correct. My point is that the decision on where to mount its volumes should not necessarily be based on the serial number. The device node name could (should?) include it, though.
Complcating the problem is that IIRC not all USB-Storage devices have serial numbers. >>Device names must still be stable enough to allow for fdisk/format >>without any surprises, though. >> >Yes and this is the hard part as it basically means that UUIDs are optional. >In addition it is entirely legitimate to write a tarball to a raw device. > Yes, as long as you can be sure that you are writing it to the intended device. The current major:minor system is simply too fragile, no matter how many layers of symlinks and daemons you use to manage /dev. What if the daemon dies at a critical time, for example? Devfs is an improvement in this respect. As long as my SCSI IDs aren't auto-assigned (and I don't add a controller or bus), I can safely have a cron job that copies /dev/scsi/c0b0t0l0p5 to /dev/scsi/c0b0t1l0p5. I can't say the same for /dev/sda5 and /dev/sdb5. USB doesn't have manually-assigned target IDs, so it can't safely fit into that model. IMHO, the best solution is to have devices appear in multiple trees. One tree for physical topology, one for USB logical device/interface/endpoint, one for storage devices w/ serials, and so on. The user can then choose the most stable one for their particular situation. -- Mark McClelland [EMAIL PROTECTED] PGP public key fingerprint: 317C 58AC 1B39 2AB0 AB96 EB38 0B6F 731F 3573 75CC _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
