| |||||||||||||
Time to switch to a "pure SCSI" systemTime to switch to a "pure SCSI" systemPosted Nov 30, 2006 15:39 UTC (Thu) by drag (subscriber, #31333)In reply to: Time to switch to a "pure SCSI" system by thedevil Parent article: Kernel release status
If you haven't used Udev for things it is worth checking out.
Nowadays the traditional /dev/sda or /dev/hda style naming is convience only. There is no reason (aside from clueless applications) why you need to follow that.
For instance I wanted to use a Debian install on a flash key on as many computers as possible. Just a sort of 'see how well it works' type thing.
Well as you know flash devices will show up as /dev/sd* stuff normally. However going from computer to computer I would run into situations were they have a onboard SATA controller or maybe other flash devices and that the /dev/sd* name would change periodicly... Obviously not something that was compatable.
Then the 'obvious' solution was to use UUID labels to point at it, but since the UUID stuff was just symbolic links pointing at the /dev/sd* device (udev you can only have one 'real' device file for each device, but can have muliple symbolic links setup in the rules) on very rare occasions it would switch around differently from the initrd vs /root so that caused weird issues.
The real solution for me was to create a udev rule based on the make and model stuff for my flash drive. It would create it's own /dev/flashdrive, and /dev/flashdrive1, /dev/flashdrive2 for the drive and it's partitions.
This worked well.
Another situation was that there was a guy posts I read were he had various iSCSI drives that would show up as /dev/sd*. Well as the system booted and such these things would be detected in different order or all of them would not be immediately aviable so he had to make persistant naming for them using custom udev rules.
So he made the /dev/sd* stuff persistant, but realy I thought he should of made the udev rules make device files names based on more usefull information, like the file system label or what system they are coming from or something like that. That way it would make remembering the names and such for scripts easier.
Other situations were udev is very good is for stuff like hotplugging input devices. For instance I have a track ball, a joystick, a wireless mouse, and a wacom pad. Now using just the regular old /dev/input/* names it's a nightmare to keep these things configured correctly. All that can change based on which order I plug them in after a reboot and it can change based on what kernel I am using and stuff like that.
Then for my laptop I may want to plug in my Wacom tablet. Now I can't use the trick to just point the X.org at /dev/input/mice, because the trackpad has special configurations for speed and other features, while the wacom pad requires having special drivers for it's Xinput extensions for sensitivity to pressure settings then every time I want to use it I pretty much would have to log out of X, and log back in to have it go into effect.
When X.org gets support for hal/dbus/udev it will make these things much easier...
Traditional /dev/ static naming or devfs is ok for machines that have realtively static hardware configurations, but in a modern machine almost anything can change at any time and it's important not to have to go back into windows 95-land were I have to restart X every time something changes.
Other situations were it would be usefull is for things like you have a print server with many multiple printer devices and such.
Now for CDROM drives and such you could, if you wanted, probably do it based on file system for special disks or whatnot, but you'd probably write the rule based on the drive information itself.
Also there is some neat stuff you can do..
Like for instance you can set it up so that when you plug in a certain specific external drive it will execute a script to automaticly mount it, and rsync your /home directory, then unmount it.
Or maybe you have a laptop or whatever you could set it up to run a script whenever you plug your cardbus wireless adapter in and such.
Or you can write a script that will run a script to identify or setup the hardware to your specific purposes then setup names based on that.
If your curious check out:
It'll show you different strings and such. So if you realy realy wanted to you can probably do your sceme were you setup specific mount points based on the cdrom label name.
(Log in to post comments)
|
|||||||||||||