[Novalug] Device naming.
James Ewing Cottrell 3rd
JECottrell3@Comcast.NET
Mon Mar 15 00:36:05 EDT 2010
Bryan J Smith wrote:
> On Sun, 2010-03-14 at 16:22 -0400, James Ewing Cottrell 3rd wrote:
>> I agree, device names are basicly unpredictable. In fact, even Fixed
>> Device names are at risk. The recent usurping of the HD (IDE) disks into
>> the SD (SCSI) driver can cause some pains.
>> For example, I have a computer with one PATA and one SATA disk. Older
>> systems call these HDA and SDA, and GRUB sees these as (hd0) and (hd1)
>> respectively. But one of my newer systems looks for the SATA drive
>> first, and calls SDB and SDA, rather than SDA and SDB.
>
> If it's at boot time, that is your BIOS. Your BIOS assigns disk 0x80
> (GRUB hd0), disk 0x81 (GRUB hd1), etc... Linux will order based on what
> drivers load in what order. If you pre-load a SCSI driver in your
> initrd, then it will pre-empt any ATA driver.
Ah, but my point is that in newer kernels (Ubuntu 9.10 and probably
later Fedoras) there *are no more* ATA drivers. Or, more to the point,
the disks don't show up as HD anymore, they show up as SD. And the SD
drivers seem to prefer SATA drives over PATA ones.
Your argument about GRUB is compelling, but the newer kernels seem to
want to call whatever device / is on /dev/sda and therefore (hd0) in
grub. Perhaps I should change /boot/grup/device.map and reinstall grub.
Don't forget that on many motherboards, when you hit F8 (or F11 or
whatever) to select a Boot Menu, whatever disk you boot off of becomes
Device 0x80.
> In fact, one of the many reasons to the unified "every read/write device
> is an sd* device" (and sr for read-only/optical) model was so one can
> use the modprobe facilities to blacklist, scsi_hostadapter re-order,
> etc... one ATA device without affecting the rest of the entire ATA
> subsystem.
>
>> And while I mount my disks by LABEL= (I think UUID= is fugly),
>
> UUID might be fugly, but UUID guarantees uniqueness. Try managing
> petabytes of SAN without LABELs, let alone device names. Furthermore,
> users have proven themselves troublemakers, and will put more than one
> disk in with more than one partition with the same LABEL. Wouldn't
> mention it if I hadn't seen it myself about ... oh ... 40 times. ;)
I'm inclined to agree with you in the Data Center, but I'm still working
on my First Petabyte; most of my machines at home (or desktop) have less
than a Terabyte.
>> what was previously HDA/(hd0) is now SDB/(hd1). Yeah, I could throw
>> two map commands into grub, but I'd rather not.
>> As for Peter's suggestion about udev, I would argue violently with the
>> word "clearly". Between HAL, UDEV, SYSFS, DEVFS, KUDZU et al (some of
>> these are obsolete), it's almost impossible to tell what is going on
>> anymore.
>
> The idea is that you don't have to. I've yet to have an issue myself in
> many, many years. But if you want to know, then writing udev rules is
> very easy.
OK, two people have said this...maybe they're not all that bad...but
clearly NO Rules beat Some Rules.
>> Yeah, I know there are Too Many Devices, but how about dividing the
>> space into Important Devices That Most People Have and bless thoss names
>> and number assignments Forever, and Weird Stuff That We Support So We
>> Can Claim We Can Run Anything and Everything and let THAT stuff be
>> assigned dynamically?
>> Make the Commonplace Easy, and the Random/Weird/Obscure stuff Hard.
>
> I think always having the first disk as "sda" and the first optical as
> "sr0" actually simplifies things. That's exactly what the new solutions
> do. The installers and distros these days are pretty good.
Yeah, when they are Upward Compatible. Some of my computers have two
disks in them, and disks of any size have 15 partitions. The layout is
Partition 15 is always swap. Partition 4 is an EXT. A different Linux
Distro is installed to each partition and grub installs into its own
partition. The MBR chains into all the others, so it's a two level boot.
A Rescue Linux is installed into A14 and the MBR points to that. If two
disks are used, B14 is /home, otherwise it's thrown in with the Rescue
Linux on A14. WIndows, if present, tends to be loaded on A1 or A2 if
there is a Dell Utility partition or similar.
Yeah, not all that common, but that's my Linux Lab.
Older systems used to install onto, say, B9 and be happy that / was
mounted on /dev/hdb9...because IT WAS. But newer systems seem to want to
be say they are sunning on /dev/sda10.
WRONG! I understand that the 37th and 38th flash drives are gonna have
different names if you plug them in in different orders, but these are
FIXED DISKS, and two kernels should AGREE on their order (A vs B), even
if they change the prefix (HD vs SD) names.
> I think it's more of an issue that people, people who were used to mix'n
> and all the conflict resolution with the older system, don't want to
> "learn the changes" -- even if they cause less conflicts.
>
> In fact, the only people I hear complaining about this are the ones who
> used to know how to hack "the old way." Learn udev and you'll be better
> off. Trust me.
BINGO! Some Change is Good. Other Change is Gratuitous.
I can deal with LABEL= and UUID= at the fstab level (will someone please
hack it into mount(8) as well?), but it would be nice if GRUB could deal
with it too.
Trust ME....I have been thru a lot of this carp too, simply because I
wanted to MAKE the system do what *I* wanted it to do, rather than
following Standard Recipes, and run into a LOT of these issues.
For example, booting kiskstart off a flash drive (sda) is easy when you
are installing to an PATA disk (hda), but rather tricky when you are
installing to a SATA drive because the Target is sdb during
installation, but sda when booted, because the flash drive will be gone
by then.
MEGA KUDOS to the Anaconda people, for Doing This Right.
Well, at least I ended on a positve note.
JIM
More information about the Novalug
mailing list