Re: should an end user stick to a kernel with an initrd?
On Sun, Sep 29, 2013 at 10:27 AM, Regid Ichira <regid23@nt1.in> wrote:
> On Sat, 28 Sep 2013 21:29:35 +0900 Joel Rees wrote:
>> On Sat, Sep 28, 2013 at 8:49 PM, Regid Ichira <regid23@nt1.in> wrote:
>> > On Fri, 27 Sep 2013 19:06:43 -0400, Tom H wrote:
>> >> [...]
>> >> As I said, more or less, in a reply to Ralf, can you guarantee that no
>> >> other Linux user will have a disk renamed?
>> >>
>> >
>> > If I understand
>> > http://www.debian.org/releases/stable/i386/apcs04.html.en correctly,
>> > then yes. I can guarantee, as long as you don't have udev rules, or
>> > other deliberate commands for renaming, including, perhaps by initrd,
>> > that no other Linux user will have a disk renamed. Hotplug devices
>> > might differ. I am not sure if hotplug devices actually require such
>> > rules to guarantee stable names.
>>
>> Old information. All disks pretend to be SCSI now.
>>
>> That's sort of part of the problem, except, even when that page was
>> correct, there were conditions not mentioned.
>>
>> If one drive spins up slow and comes up to speed out of order, the names change.
>>
>> For instance, you have three ATA disks attached in a certain order.
>> They would usually be given the spin-up command in the order they are
>> attached, and they would usually spin up in the same order.
>>
>> If, for some reason, they spin up out of order, your naming changes.
>>
>
> I am not familiar with the ATA protocol.
I'd rag on you for theorizing about a protocol you are not familiar
with, but, hey, no one really knows what the protocol is. It's an
ad-hoc mess that, on the one hand, allows implementers lots of room to
cut corners, get a product to market, make profits, etc., but on the
other hand, outside of the manufacturer's declaration of intended use,
practically nothing is promised. And even in the manufacturer's
declaration of intended use there are lots of weasel words. The upshot
is that they only get excited if you can't get it to work with
MSWindows, with the manufacturer supplied drivers, running according
to the mostly unwritten rules Microsoft runs by and changes at their
own convenience.
ATA is one of the sins of Intel. Our sin is that we keep buying it from them.
> Are you saying that the
> kernel has no way to know the time on which each disk spined up?
I don't think I said that at all.
> Doesn't the disk returns a SPINED_UP_AND_WAITING response, together
> with its unique address?
Signal names are different, meaning is ever-so-slightly different,
and, oh, the controller is supposed to know which drive it's talking
to, so the disk doesn't bother saying. That's the whole reason for the
channel and master/slave arrangement. Malformed star topology.
The system and the hardware are supposed to cooperate to yield a
unique ID if the system thinks such things are necessary, and the
hardware, as I noted above, often cooperates by its own rules (if at
all).
SATA fixes some of that, maybe a lot of that, more so in recent
devices, but the kernel developers don't think it is their
responsibility to kick all the old hardware off the edge of the world,
so they can't rely on new parts of the spec. (And those improved parts
of the spec are still not uniformly and universally implemented in new
hardware, so we aren't really talking about just eliminating old
hardware from Linux support.)
> With scsi, the disk address is determined by its physical
> connection to the scsi cable. On the scsi cable, there is always a
> connector that is most closest to the scsi controller. And a
> connector that is next to the closest one, and so on.
You know, that doesn't sound like any SCSI I know, so I can't address
your theory at all beyond the above. The parallel SCSI devices I have
include a rotary switch that sets a 3 (well, 4) bit ID that,
concatenated to the bus id, becomes the SCSI id. Completely position
independent. Looking at the entry on SAS on Wikipedia, it looks like
manufactures are putting UUIDs in the devices themselves, comparable
to the MAC address on a NIC, I suppose, so there should be no position
dependency.
With real SCSI devices, but we don't have those.
Anyway, as Doug points out, it's not the devices themselves pretending
to be SCSI, it's the drivers presenting them as SCSI. The drivers are
manufacturing IDs with little reliable support from the devices
themselves. Thus the tendency towards the sins of UUIDs.
--
Joel Rees
Be careful where you see conspiracy.
Look first in your own heart.
Reply to: