On Thu, Nov 3, 2011 at 12:08 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> 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
>
>
Adding the fsync() in do_prevent_allow() make the code more robust
and friendly
for final user, if not, it might not be one issue for one self-powered system.
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
