On Sun, Sep 29, 2013 at 10:27 AM, Regid Ichira <regi...@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 <regi...@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. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAr43iP99dEcfLMuQ3_=tHiWir=vs9ba5rhmcoe-cdkmodh...@mail.gmail.com
