>-----Original Message----- >From: Michal Nazarewicz [mailto:mpn@xxxxxxxxxx] On Behalf Of Michal >Nazarewicz >Sent: 2012年9月21日 19:23 >To: Leo Song; Felipe Balbi; linux-usb@xxxxxxxxxxxxxxx >Cc: Leo Song >Subject: Re: [PATCH] USB: g_mass_storage: Hide caching mode page to improve >write speed for Windows > >On Fri, Sep 21 2012, Leo Song wrote: >> If connect an UMS device (for example, an Android phone) to Linux PC >> and Windows PC, then copy a big file (~500MB) to the device, you will >> find that Linux PC's write speed is much faster than Windows PC. This >> issue can be fixed by hiding the "caching mode page" on UMS device. >> >> Previously in f_mass_storage.c: do_mode_sense(), caching mode page was >> the only mode page, and it was configured as: >> Write cache enabled (WCE=1) >> Read cache not disabled >> No cache retention priorities >> >> The "Write cache enable"(WCE) bit has different influence for Linux PC >> and Windows PC. >> >> For Linux PC, whether WCE is 0 or 1, the write speed from Linux PC to >> UMS device has no difference. Linux PC just ignores this flag. >> >> For Windows PC, if >> 1. the UMS devices has a valid "caching mode page" >> 2. the WCE bit in "caching mode page" is set to 1 >> 3. the "write-cache buffer flushing" on Windows PC is not turned off >> >> With these three conditions together, Windows PC will send SCSI WRITE >> COMMAND with FUA=1 (FUA, force unit access), and FUA=1 will cause UMS >> device to wait until the blocks have been written onto the medium, >> which will drag down write speed a lot. Unluckily, this is Windows PC's default >behavior. >> >> On Windows, the FUA=1 flag can be changed by turning off "write-cache >> buffer flushing" under UMS device's properties, but if we do so, >> Windows will pop up error message as following: >> >> Windows could not change the write-caching setting for the device. >> Your device might not support this feature or changing the setting. >> [ OK ] >> >> Windows need to change UMS device's caching mode page, but this page >> is hard coded and can't be changed, so there will be error pop up. >> >> To fix this issue, we can just hide the "caching mode page". With this >> patch, there will be no influence for Linux PC, because Linux PC does >> not handle UMS device's caching mode page; for Windows PC, if it does >> see the "caching mode page", it will not send SCSI WRITE COMMAND with >> FUA=1, and write speed will become as fast as Linux PC. > >How does it interact with the nofua attribute? With f_mass_storage, you can write 1 to >nofua file in sysfs's directory for given lun to make it ignore the FUA bit. > Actually this patch does not interact with the nofua attribute directly. The original code will let Windows PC go into a confused 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. 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. Leo ��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
