2011/11/3 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > On Wed, 2 Nov 2011, Barry Song wrote: > >> > You know what? I finally remembered to look at the SCSI spec's >> > description of PREVENT ALLOW MEDIUM REMOVAL: >> > >> > The prevention of medium removal shall begin when any initiator >> > issues a PREVENT ALLOW MEDIUM REMOVAL command with a prevent >> > bit of one (medium removal prevented). The prevention of medium >> > removal for the logical unit shall terminate: >> > >> > a) after all initiators that have medium removal >> > prevented issue PREVENT ALLOW MEDIUM REMOVAL commands >> > with a prevent bit of zero, and the target has >> > successfully performed a synchronize cache operation; >> > >> > b) upon the receipt of a BUS DEVICE RESET message from any >> > initiator; or >> > >> > c) upon a hard RESET condition. >> > >> > The last line of a) indicates that we really do need to keep the >> > fsg_lun_fsync_sub() calls where they are. We probably could skip the >> > sync if the backing storage is a regular file, because in that case it >> > shouldn't be removed until its filesystem is unmounted, and unmounting >> > syncs the page cache. >> >> Alan, after thinking in the recent several days, i think we both have >> misunderstood the meaning of cache operation in the description. >> >> "the target has successfully performed a synchronize cache operation", >> for a real u-disk, > > What's a "u-disk"? > >> the cache means HW cache on disk controller and >> "PREVENT ALLOW MEDIUM REMOVAL" just means we can safely unplug the >> disk after that. if we don't do sync and unplug the disk after doing >> "PREVENT ALLOW MEDIUM REMOVAL", data will be wrong since HW cache is >> not flushed into physical disk. > > That's more or less right, except that you talk about unplugging a disk > when you really should be talking about removing the medium (for > example, taking a card out of a reader or ejecting a disc from a > DVD-RAM drive). > >> But for USB gadget, it is much different actually. in fact, page cache >> for gadget file is a thing on target board and has nothing to do with >> the PC, it is just transprant to PC at all. PC can think all data has >> been in U-disk after they execute any read/write commands. no matter >> data is in page cache or in gagdet device, it has been in the U-disk >> to PC. so i think we can't do fsync in gadget in the case "PREVENT >> ALLOW MEDIUM REMOVAL" , all data has been in target board(the U-disk), >> either in target board memory and target board gagdet-specific file or >> partition. Then the target board need to take over the responsiblity >> to flush page cache into physical medium before users unplug the card >> bound with gagdet. >> >> actually, no matter a disk is bound with gadget or not, once it is >> written by any program and any user on target board, users need to >> realize a sync/eject is needed before unplugging it. that is the >> meaning i said gadget is just a program to access a writeable vfs >> node. > > I agree, we can remove the call in do_prevent_allow(). But it would be > a good idea to add a comment explaining that we disobey the SCSI spec > here because the cache will be synced later in fsg_lun_close(). If the > user removes the physical storage before doing a logical eject then the > data may be corrupted; but that has always been true for Linux systems. so gadget driver can either not do sync at all(leave that job to linux and users) or only do fsync when it wants to close the file it uses. the gadget driver, as an user of vfs, it might make sense to sync the file it uses before it doesn't want to use it. so i think yuping's last patch is kind of right. > > Alan Stern -barry -- 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
