On Thu, Oct 27, 2011 at 11:27 AM, Barry Song <Barry.Song@xxxxxxx> wrote: >> -----Original Message----- >> From: Yuping Luo [mailto:lypingsh@xxxxxxxxx] >> Sent: 2011年10月27日 9:44 >> To: Alan Stern >> Cc: balbi@xxxxxx; mina86@xxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx; >> DL-SHA-WorkGroupLinux >> Subject: Re: usb-storage: fsync() take too much time when handing >> ALLOW_MEDIUM_REMOVAL >> >> 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 ? > > I'd like to think doing fsync in gadget driver is wrong. It is not the duty of gadget driver but the duty of pdflush and users. I think the storage gadget just act as one glue layer, or proxy, which handle one file (just like one normal linux file) or block device, and need explicitly be told what to do by the user from host. > This gadget is only one of many users of fs through standard vfs interface. There are many users who might access the related storage. We can't stop them actually. if the backing file exported to PC, it should not be used by the system , right ? > I would think the fsync should be done by user explicitly before he unplugs a card. Otherwise, let the data bad. > Yeah, that's the role of SYNCHRONIZE_CACHE, however, not sure why ALLOW_MEDIUM_REMOVAL sent. Yuping Luo >> >> > Alan Stern >> > >> > >> >> Thanks >> Yuping Luo >> > -barry > > > Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom > More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog > -- 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
