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





      
____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs
-
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

Reply via email to