On Wed, Oct 26, 2011 at 10:38 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, 26 Oct 2011, Yuping Luo wrote:
>
>> Hi,
>> I have one slow flash block device, which act as usb-mass storage
>> device, and during the data transfer with windows PC, it will get
>> ALLOW_MEDIUM_REMOVAL , and sync the file system cache, however, it
>> takes too much time (by log about 10s) and the usb reset occurs.
>> however, if the /proc/sys/vm_dirty_ratio changed from 20 to 0 or 4,
>> everything is ok.
>> I made some code change to defer the file cache flash for your
>> review, currently the do_verify() and do_synchronize_cache() not
>> touched.
>
> What happens if you simply remove the call to fsg_lun_fsync_sub() in
> do_prevent_allow()? In particular, what happens to the next command,
> which ought to be START STOP UNIT with the loej bit set? When
> do_start_stop() calls fsg_lun_close(), that should also sync the
> filesystem cache. (Otherwise, if the backing storage was on a flash
> card, the user might remove the card while there still some dirty
> buffers.)
>
Removal of fsg_lun_fsync_sub() can pass my test, however, I found under
linux host (specifically ubuntu 11.10) there is no SYNCHRONIZE CACHE
coming when ejecting the mount point, only ALLOW_MEDIUM_REMOVAL().
while it has under windows XP. also the START-STOP UNIT is not present
for both case.
> Doing the operation in the background is not a good idea. If flushing
> the dirty buffers out to the flash storage really is a slow operation,
> we _want_ the host to realize that it is slow. Most especially, we do
> not want the host to tell the user that it's okay to remove the medium
> before all the buffers have been written out.
>
yes, it's a workaround, does scsi spec define the timer for such commands, or
implementation dependent ?
> Alan Stern
>
>
Thanks
Yuping Luo
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
