[Discuss] Disk numbering

[gaf at blu.org (Jerry Feldman)]

On 10/05/2011 02:26 AM, Jon Masters wrote:
> On Sat, 2011-10-01 at 14:36 -0400, Jerry Feldman wrote:
>> On 10/01/2011 10:49 AM, Matt Iavarone wrote:
>>> On 10/01/2011 10:26 AM, Jerry Feldman wrote:
>>>> 2 weeks ago when I added a new 1.5TB ($49) HD to use as backup, my
>>>> drives were numbered sda, sdd, sde, and sdf. This prompted me to rewrite
>>>> my weekly disk health script to discover what drives are on my system.
>>>> All well and good. My /etc/fstab uses only UUID as does my RAID1. I shut
>>>> my system down last week when I went out of town for a couple of days,
>>>> and I found that the drives were renumbered again. I don't recall the
>>>> exact numbering, since I don't have anything that uses the drive numbers
>>>> other than my health script.  When I returned, I noticed an I/O error on
>>>> the new drive so I spent hours running fsck to bypass the bad blocks and
>>>> fix any errors. I'm watching closely to see over the next few days in
>>>> case I need to return the drive. After the fsck was completed, and the
>>>> drive tested good, I rebooted, and this morning I noticed another
>>>> renumbering (sda, sdb, sdc, sdd). The backup drive that was repaired is
>>>> still /dev/sdc. Now sda and sdb are the RAID1 pair.
>>>>
>>>> I guess I am just ranting because I know the kernel assigns the drive
>>>> numbers at boot time and I don't need to know anything about the drive
>>>> numbers unless I need to run something manually.
> There is an extension to SCSI called the SCSI Enclosure Services (SES)
> that can report disk ordering, and I have proposed additions to ACPI for
> manufacturers to provide such ordering in their DSDTs, but fundamentally
> the problem is that the Linux community doesn't care enough about
> solving this problem in the way that users like yourself are asking. 
>
> There is a belief that udev rules and so on will solve everything but
> the kernel and tools still deals with block device names in many places.
> Until we get beyond the desktop-centric view that no admin needs to know
> what kernel device names are in use, this is an ongoing problem.
>
>>> If you have dependencies on the disk lettering, then you can use udev
>>> rules to force them.
>> True, but the best way is not to depend on disk numbering at all,
>> especially when you have removable drives like I do. In my case above it
>> was just a bit comical that they got renumbered several times in the
>> last couple of weeks.
> This kind of thing drives me nuts too. I'm trying to get this stuff
> fixed properly when I have cycles by requiring that system vendors
> provide information about slot arrangements and we solve this the right
> way - changing enumeration, use of volume UUIDs, etc. are all hacks.
>
I agree with what you are saying. With arrays of slots on todays
servers, it is very difficult to determine what slot a specific drive is
in. This also includes my home system that has SATA slots. But, it is
even worse at work and at the BLU where we have a system that has 10
SCSI slots and 2 SCSI channels. Trying to determine what drive is what
is a pain. Most drives have the UUID printed on the label, but at the
BLU we had 1 drive where the UUID was not on the label.  Let's say I
have a drive that is reporting errors. I can easily unmount that drive,
but I don't want to pull it out of a running system (even though hot
swap is supported) because I could possibly pull the wrong drive. At
work, most of my drives have a sticky label. As I mentioned, I don't
really care about how Linux assigns the drive numbers because mounting
(or RAID grouping) by UUID works, but there is really nothing that
points to a physical slot. Linux is not the only system to have this
problem. In Windows, you might have several drives, and you often don't
know whether a certain drive is going to show up as D:, E:, etc.
Fortunately I don't have any physical Windows servers.

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90 
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90