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. Alan Stern -- 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
