>>>>> "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.
pgpAoBbGUMwdU.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
