|
Page 20 of 26
19. The kernel 2.6.20
Somewhere on the road from 2.6.19 and 2.6.20, a major change happened: «First, the big change is the migration away from the crusty old parallel ATA drivers to shiny new ones that use the same libata infrastructure as the SATA drivers. A side effect of this is that /dev/hda becomes /dev/sda. This isn't a problem if you're using 'mount by label' (which has been the default in Fedora since forever). If you aren't, well, it's going to be fun.»
Manually compiling a 2.6.20 kernel took by surprise some people, when «the harddrive had switched dev file from hda to sda and the DVD drive had taken the place of hda.»
As a matter of fact, I have experienced some moody behaviors with Ubuntu Feisty (Beta): - kernel 2.6.20-12: IDE (PATA) /dev/hda goes /dev/sda
- kernel 2.6.20-13: IDE (PATA) is seen again as /dev/hda
- kernel 2.6.20-14: IDE (PATA) /dev/hda goes again /dev/sda
The /dev/hdb IDE CD-ROM is seen as /dev/scd0 by the unified driver.
My first reaction believe that starting with 2.6.20, the Linux kernel shoud have had a new tagline: «How Do You Want Your Devices To Be Called Today?»
And indeed, forcefully treating a device as a different device, and changing its identification in the process is revolting: an IDE PATA hard-disk and an IDE CD-ROM will never have assigned SCSI-like device names in BSD-based operating systems such as FreeBSD or Solaris!
At least, device names have a meaning in BSD-land. I agree that using a SATA driver with a PATA disk works, but why forcing it? I thought the philosophy of forcing the users was a Microsoft one, not an open source concept. Even so, when Microsoft did the same thing in Windows NT, replacing the "scsidisk" driver with "disk", it was the other way around: a more generic name was used, which made the value of truth unchanged. Any SCSI disk is indeed a "disk", but not all the disks are SCSI disks!
Chuck Ebbert from Red Hat told me that dropping the old PATA driver was justified, as there are horrible IDE bugs with hot-pluggable drives. However, there is a problem: «The real problem is that SCSI only supports 15 partitions per disk while the old IDE driver supports more (31?) Nobody has an answer for that one...»
To me, this is just another proof that the decision to treat everything through the SCSI driver was a hasty one. Automated updates of a production system that go into hdX becoming sdX will break things like automated backup, mounts, exported NFS, and even RAID.
Mounting by label is supposed to be immune to device name changes. And Red Hat distros are using it by default. There are however two CONs to that answer.
First, some other distros (Ubuntu) are using udev-provided UUIDs in GRUB instead of LABELs when with the SATA driver (root=UUID=c18758e8-a5c2-4921-816a-f235542574a2). One size does not fit all.
Secondly, there is a lot of software that will still break, for it's using the more intuitive device name. Some examples include raidtools (raidtab) and mdadm (mdadm.conf): they both use /dev names and will need manual fixes.
The irresponsible changes in the Linux kernel contrast with the conservative approach of the *BSD family of operating systems, whose wisdom says that something that worked yesterday is not supposed to break tomorrow.
Unfortunately, the kernel team does its job and takes the decisions without a previous poll with all the mainstream distro makers, albeit some of them (Red Hat, Novell) are employing kernel developers. This is decentralized software development.
Coming after a 2.6.19 kernel that was breaking all distros older than ten months, I wonder whether you're supposed to be expecting for less every day when running Linux. I for one am expecting for more.
Therefore, 2.6.20 might be the sign that you should switch to *BSD.
|
Articles 
