I can't understand what is going on with yahoo. My reply seemed perfectly
normal before sending. Hopefully this comes through a little prettier ...
From: Alan Stern <[EMAIL PROTECTED]>
> On Fri, 15 Feb 2008, tike64 wrote:
>> I have an annoying problem: When I have an USB memory stick attached
>> and then detach it while I have a file open on it, the device node is
>> left reserved even if it disappears from the /dev dir. If the device
>> node was /dev/sda then next time it would be /dev/sdb. Additional
>> symptom is that the related scsi_eh_? process doesn't die.
>> ...
> It isn't a problem at all; it is the desired behavior. As long as the
> file remains open, the kernel has to maintain the device node
> (internally if not externally) and the SCSI error-handler process.
> Thus the node name is not available for new devices to use.
But I'm pretty sure the device node remains reserved even after closing the
file and that is the problem.
> ...
>> Is there some kind of workaround?
>
> Yes indeed: Close the open files and unmount the filesystem before
> unplugging the memory stick. This is just good practice in any case;
> if you don't follow it then you risk losing data.
Yes the risk losing data is obvious but leaking system resources is simply
wrong. In real life in 24/7 system it is bound to happen that the user detaches
the stick at wrong moment. Data loss can be fixed by asking the user to put the
stick back. But if the system resources are leaking it means eventually a need
for rebooting and that is wrong. My ubuntu desktop system doesn't have this
problem and that tells me that the problem is introduced by the older kernel
version, ARM environment or the buildroot generated user space.
--
Timo
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
