On Fri, 21 Sep 2012, Leo Song wrote: > Actually this patch does not interact with the nofua attribute > directly. The original code will let Windows PC go into a confused What's confused about it? > state, and Windows will always send WRITE COMMAND with FUA=1. If > manually "echo 1 > ./f_mass_storage/lun/nofua" to let the UMS device > ignore the FUA bit from host PC, it can improve write speed. > > But with original code, if you check the properties of the UMS device > in Windows Device Manger, there is an unpleasant yellow "!" under the > "Policies" item, and the "Removal policy" is fixed to "Better > performance". If you try to change to "Quick removal", Windows will > cry. This is very different with a normal USB flash disk, and > unfriendly to end user. It is more friendly than slowing down all the accesses by forcing each write out to permanent storage immediately. > This patch's solution is to hide the "caching mode page", if Windows > does not see this page, it will not be confused, and will not send > WRITE COMMAND with FUA=1, so that write speed will be fast. > > With this patch, the unpleasant yellow "!" will disappear, and > "Removal policy" will be "Quick removal" by default, and you can > change to "Better performance" if you want. It will be the same as a > normal USB flash disk. Normal USB flash disks don't have an internal cache. Linux systems do. It's appropriate for the gadget to be different from a flash disk. You should compare the mass-storage gadget to a real USB-based disk drive (i.e., one with rotating media) instead of to a flash drive. Many disk drives have an internal cache and they inform Windows about it. How does Windows react to them? 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
