On 10 maj 2010, at 20.04, Miles Nordin wrote: >>>>>> "bh" == Brandon High <bh...@freaks.com> writes: > > bh> The drive should be on the same USB port because the device > bh> path is saved in the zpool.cache. If you removed the > bh> zpool.cache, it wouldn't matter where the drive was plugged > bh> in. > > I thought it was supposed to go by devid. > > There was a bug a while ago that Solaris won't calculate devid for > devices that say over SCSI they are ``removeable'' because, in the > sense that a DynaMO or DVD-R is ``removeable'', the serial number > returned by various identity commands or mode pages isn't bound to any > set of stored bits, and the way devid's are used throughout Solaris > means they are like a namespace or an array-of for a set of bit-stores > so it's not appropriate for a DVD-R drive to have a devid. A DVD disc > could have one, though---in fact a release of a pressed disc could > appropriately have a non-serialized devid. However USB stick > designers used to working with Microsoft don't bother to think through > how the SCSI architecture should work in a sane world because they are > used to reading chatty-idiot Microsoft manuals, so they fill out the > page like a beaurocratic form with whatever feels appropriate and mark > USB sticks ``removeable'', which according to the standard and to a > sane implementer is a warning that the virtual SCSI disk attached to > the virtual SCSI host adapter inside the USB pod might be soldered to > removeable FLASH chips. It's quite stupid because before the OS has > even determined what kind of USB device is plugged in, it already > knows the device is removeable in that sense, just like it knows > hot-swap SATA is removeable. USB is no more removeable, even in > practical use, than SATA. (eSATA! *slap*) Even in the case of CF > readers, it's probably wrong most of the time to set the removeable > SCSI flag because the connection that's severable is between the > virtual SCSI adapter in the ``reader'' and the virtual SCSI disk in > the CF/SD/... card, while the removeable flag indicates severability > between SCSI disk and storage medium. In the CF/SD/... reader case > the serial number in the IDENTIFY command or mode pages will come from > CF/SD/... and remain bound to the bits. The only case that might call > for setting the bit is where the adapter is synthesizing a fake mode > page where the removeable bit appears, but even then the bit should be > clear so long as any serialized fields in other commands and mode > pages are still serialized somehow (whether synthesized or not). > Actual removeable in-the-scsi-standard's-sense HARD DISK drives mostly > don't exist, and real removeable things in the real world attach as > optical where an understanding of their removeability is embedded in > the driver: ANYTHING the cd driver attaches will be treated > removeable. > > consequently the bit is useless to the way solaris is using it, and > does little more than break USB support in ways like this, but the > developers refuse to let go of their dreams about what the bit was > supposed to mean even though a flood of reality has guaranteed at this > point their dream will never come true. I think there was some > magical simon-sez flag they added to /kernel/drv/whatever.conf so the > bug could be closed, so you might go hunting for that flag in which > they will surely want you to encode in a baroque case-sensitive > undocumented notation that ``The Microtraveler model 477217045 serial > 80502813 attached to driver/hub/hub/port/function has a LYING > REMOVEABLE FLAG'', but maybe you can somehow set it to '*' and rejoin > reality. Still this won't help you on livecd's. It's probably wiser > to walk away from USB unless/until there's a serious will to adopt the > practical mindset needed to support it reasonably.
I'm sorry if I am slow, but I don't get it; Whys isn't devid calculated for removable devices? What does the serial number has to do with devid? /ragge _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
