Hmm, makes a bit more sense then.

The GUID I get is just the vendor & product IDs and a load of 0's (05e307020000000000000000). I have two of the devices, and they both give exactly the same number. Are they supposed to have a unique id component as well?

If I plug in a different device I do get another SCSI node, but even the GUID for that is just the vendor and product components (353800220000000000000000).

However, the picture is made more complicated because the device is in fact a USB/IDE adaptor which I have fitted to a drive caddy. This gives me the ability to hot-plug IDE drives in caddies - great idea (I thought). I have one of them on my Windows XP box, and one on my Linux server, primarily as backup devices.

It sounds like the Linux strategy for USB devices won't work in this situation, because if I swap the IDE drive, the USB adaptor is still the same (regardless of whether it yields a unique GUID or not). Windows allows me to swap drives in this way quite happily - I can even do partition management on them.

It strikes me the Linux USB mass-storage design is a bit broken in this respect. I can understand the idea of creating a "sticky" device node, but it clearly doesn't work as desired in all scenarios.

Is there any way at user level to force a virtual SCSI node to be dropped?

Failing that, any other ideas welcome.

Thanks for your input.

--On 14 March 2004 07:54 -0800 "Stephen J. Gowdy" <[EMAIL PROTECTED]> wrote:

[cc back to the list incase someone understand more than I do]

Ah, I missread what you said then. Each device should create use a new
/dev/sdX. It uses the devices GUID to detect if it has already been
connected or not. Can you can /proc/scsi/usb-storage-0/0 (I think, I don't
have a device handy to check the exact name, but hopefully you can find it
from this hint) and see if the GUID is the same for both devices? If they
are I think they are technically broken devices. What others have seen
which is more annoying than anything else is devices that have difference
GUIDs every time you connect them, so you get a whole bunch of devices
used.

On Sun, 14 Mar 2004, Rick Jones wrote:

Nice idea, but in fact it doesn't work. It rejects /dev/sda as "invalid
argument".

As I understand it, the "eject" commands are used to exchange media in
removable-media drives, whereas USB hotplugging involves exchanging the
drive itself - subtly different. A hard drive connected to a USB port is
not flagged as "removable" in the sense of a CDROM or ZIP, etc.

There seems to be a fundamental flaw here, I can't believe that there are
no Linux users who swap different size drives in the same USB port.

Either I'm missing something, or the rest of the world is (seems
unlikely) :-/

Rick Jones

--On 13 March 2004 15:02 -0800 "Stephen J. Gowdy"
<[EMAIL PROTECTED]> wrote:

> Try 'eject /dev/sda'.
>
> On Sat, 13 Mar 2004, Rick Jones wrote:
>
>> I have a problem doing a hot-swap of one USB drive with another, when
>> the two drives are different sizes.
>>
>> This appears to be because the pseudo-SCSI device entry that's created
>> when the first device is connected does not get cleared down when the
>> device is removed. The SCSI device loads the drive geometry table, and
>> this is persistent even when another drive is connected. The new
>> drive's partition info is at odds with the old geometry parameters,
>> which leads to various errors.
>>
>> This is on a 2.4 kernel - the distro I'm running (SME server) uses
>> 2.4.20, and I've tried building a 2.4.25 kernel but there's no
>> difference in behaviour.
>>
>> This site - http://www2.one-eyed-alien.net/~mdharm/linux-usb/ -
>> suggests that this behaviour is in fact by design, which seems
>> somewhat odd to me, unless I've misunderstood what is meant.
>>
>> Hot-plugging is a bit pointless if you can't swap devices of different
>> geometry, so I'm rather mystified at this restriction. Has this been
>> fixed in later kernels, and can a fix be hacked into 2.4?
>>
>> Or am I missing something and there's a completely different
>> explanation?
>>
>> TIA
>> Rick Jones
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IBM Linux Tutorials
>> Free Linux tutorial presented by Daniel Robbins, President and CEO of
>> GenToo technologies. Learn everything from fundamentals to system
>> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>> _______________________________________________
>> [EMAIL PROTECTED]
>> To unsubscribe, use the last form field at:
>> https://lists.sourceforge.net/lists/listinfo/linux-usb-users
>>
>
> --
>  /------------------------------------+-------------------------\
>| Stephen J. Gowdy                     | SLAC, MailStop 34,       |
>| http://www.slac.stanford.edu/~gowdy/ | 2575 Sand Hill Road,     |
>| http://calendar.yahoo.com/gowdy      | Menlo Park CA 94025, USA |
>| EMail: [EMAIL PROTECTED]       | Tel: +1 650 926 3144     |
>  \------------------------------------+-------------------------/
>



-- /------------------------------------+-------------------------\ | Stephen J. Gowdy | SLAC, MailStop 34, | | http://www.slac.stanford.edu/~gowdy/ | 2575 Sand Hill Road, | | http://calendar.yahoo.com/gowdy | Menlo Park CA 94025, USA | | EMail: [EMAIL PROTECTED] | Tel: +1 650 926 3144 | \------------------------------------+-------------------------/





-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users

Reply via email to