Re: usb-storage: fsync() take too much time when handing ALLOW_MEDIUM_REMOVAL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2011/10/27 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>:
> On Thu, 27 Oct 2011, Barry Song wrote:
>
>> > It depends on what you're using for the backing storage.  If the
>> > backing storage is a regular file, then yes, write-back is okay.
>> >
>> > But if the backing storage is a block device (especially a removable
>> > block device like a flash memory card), then the act of closing the
>> > backing file ought to flush the page cache.  (I'm not sure if this
>> > actually happens -- I haven't checked -- but I think it does.)  When
>> > this happens, you'll have to wait for the flush to finish anyway.
>>
>> suppose we use a file not disk partition as back device,  umount or
>> eject should be the one requiring sync fs but not the ALLOW MEDIUM
>> REMOVAL. this command only unlock the device.
>> i would think we should handle the fsync in umount/eject, that is what
>> fs will do. so fsg driver doesn't need it.
>> if users don't umount/eject before pulling cards and don't sync
>> manually as well, it is normal that their data will be corrupted.
>
> That's exactly what I concluded:
>
>> > Perhaps you can make the call to fsg_lun_fsync_sub() conditional, based
>> > on whether the backing storage is a regular file.
>
>> suppose users use a SD card partition as back file, will we move the
>> fsync to STOP command instead of "ALLOW MEDIUM REMOVAL"? are you sure
>> STOP command is the one following "ALLOW MEDIUM REMOVAL",
>
> Look, I don't know exactly what messages Windows sends.  Windows is a
> mystery to me.
>
>>  if no, a
>> fsync in "ALLOW MEDIUM REMOVAL" is still wrong in case we write the
>> storage after "ALLOW MEDIUM REMOVAL".
>
> Did you understand when I said that closing the backing file would
> flush the page cache if the backing file is a device?

that is not important. my point is we can just think this gadget as an
user to vfs on target board, actually it is.
so there is no any necessarity to do any fsync at all.

when target board is disconnected from pc, pc has the duty to do the
fsync to this gadget. after that, the board which this gadget works on
takes the duty to do fsync. all should be done by generic OS way but
not by gadget itself.

>
> 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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux