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