From: Joaquim Duran <joaquinduran@adtelecom.es>
To: linux-scsi@vger.kernel.org
Subject: File operation on removed USB memory stick
Date: Wed, 23 Jan 2008 11:17:35 +0100 [thread overview]
Message-ID: <4797143F.8000400@adtelecom.es> (raw)
Dear all,
I'm new to this e-mail list. My name is Joaquim Duran.
I've detected a behavior of the SCSI system that could be improved when
accessing to a removed USB memory stick.
That is, I was playing musing from a mounted USB stick, then I removed
it while the program was still running. The program stopped with an
error after few seconds. I checked the message log file and saw that the
I/O operations to a file of the memory stick were done 3 times before
notify the fault to the application. The logs:
Jan 23 09:36:47 adlab127 sdf: sdf1
Jan 23 09:36:47 adlab127 sd 2:0:0:0: [sdf] Attached SCSI removable disk
Jan 23 09:36:47 adlab127 sd 2:0:0:0: Attached scsi generic sg4 type 0
Jan 23 09:36:47 adlab127 usb-storage: device scan complete
Jan 23 09:36:47 adlab127 scsi 1:0:0:0: rejecting I/O to dead device
Jan 23 09:36:47 adlab127 FAT: Directory bread(block 127) failed
Jan 23 09:36:47 adlab127 scsi 1:0:0:0: rejecting I/O to dead device
Jan 23 09:36:47 adlab127 FAT: Directory bread(block 128) failed
Jan 23 09:36:47 adlab127 scsi 1:0:0:0: rejecting I/O to dead device
Jan 23 09:36:47 adlab127 FAT: Directory bread(block 129) failed
Jan 23 09:36:47 adlab127 scsi 1:0:0:0: rejecting I/O to dead device
Jan 23 09:36:47 adlab127 FAT: Directory bread(block 130) failed
Jan 23 09:36:47 adlab127 scsi 1:0:0:0: rejecting I/O to dead device
Jan 23 09:36:47 adlab127 FAT: Directory bread(block 131) failed
Jan 23 09:36:47 adlab127 scsi 1:0:0:0: rejecting I/O to dead device
Jan 23 09:36:47 adlab127 FAT: Directory bread(block 132) failed
Jan 23 09:36:47 adlab127 scsi 1:0:0:0: rejecting I/O to dead device
Jan 23 09:36:47 adlab127 FAT: Directory bread(block 133) failed
Jan 23 09:36:47 adlab127 scsi 1:0:0:0: rejecting I/O to dead device
Jan 23 09:36:47 adlab127 FAT: Directory bread(block 134) failed
Jan 23 09:36:47 adlab127 scsi 1:0:0:0: rejecting I/O to dead device
Jan 23 09:36:47 adlab127 FAT: Directory bread(block 127) failed
Jan 23 09:36:47 adlab127 scsi 1:0:0:0: rejecting I/O to dead device
Jan 23 09:36:47 adlab127 FAT: Directory bread(block 128) failed
Jan 23 09:36:47 adlab127 scsi 1:0:0:0: rejecting I/O to dead device
Jan 23 09:36:47 adlab127 FAT: Directory bread(block 129) failed
Jan 23 09:36:47 adlab127 scsi 1:0:0:0: rejecting I/O to dead device
Jan 23 09:36:47 adlab127 FAT: Directory bread(block 130) failed
Jan 23 09:36:47 adlab127 scsi 1:0:0:0: rejecting I/O to dead device
Jan 23 09:36:47 adlab127 FAT: Directory bread(block 131) failed
Jan 23 09:36:47 adlab127 scsi 1:0:0:0: rejecting I/O to dead device
Jan 23 09:36:47 adlab127 FAT: Directory bread(block 132) failed
Jan 23 09:36:47 adlab127 scsi 1:0:0:0: rejecting I/O to dead device
Jan 23 09:36:47 adlab127 FAT: Directory bread(block 133) failed
Jan 23 09:36:47 adlab127 scsi 1:0:0:0: rejecting I/O to dead device
Jan 23 09:36:47 adlab127 FAT: Directory bread(block 134) failed
Jan 23 09:36:58 adlab127 scsi 1:0:0:0: rejecting I/O to dead device
Jan 23 09:36:58 adlab127 FAT: unable to read inode block for updating
(i_pos 7582155)
If the memory stick has been removed, a more severe error could be
notified to the application avoiding the repetition of the operations.
In general IMHO, the behavior to this situation would be:
1 - Move all cache blocks of the removed memory USB stick to the free list.
2 - Any operation relating to the removed device be notified as a severe
error avoiding repetitions.
because if the USB stick is removed in inserted once again it will be
mounted as a different device that the current one, because as still
there is files in use, the device could not be unmounted from system.
Thanks and Best Regards,
Joaquim Duran
reply other threads:[~2008-01-23 9:30 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4797143F.8000400@adtelecom.es \
--to=joaquinduran@adtelecom.es \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.