Questions like this should always be CC'ed to the appropriate mailing list. (And note that the mailing list does not accept messages in HTML format.) On Thu, 29 Aug 2019, sandeep krishnaswamy wrote: > Hi Alan, > > > > We are using the Android 8.x (i.e Android ‘O’) with Android kernel 4.9.182 > (derived from open source Linux kernel 4.9.182) > > > > Since Android does not support the NTFS by default, we have enabled NTFS > support in Kernel & added changes in user space to mount NTFS USB drives > (as part of Android Vold). > > > > With the integration of K4.9.182, we have seen regression in read speed > from NTFS mounted USB drive. FAT32 mounted USB drives read speeds are fine > without any regression. > > > > By reverting the commit - > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/usb/storage/scsiglue.c?h=v4.9.190&id=c685caf6e5d896472c67b348d23936c6dc479749 > , I could see read speed of NTFS mounted USB drives are fine. > > > > Could you please help me to understand the commit and help me, how this > commit could impact only on NTFS mounted USB drive but not with FAT32 > mounted USB drive ? I have no idea how that commit could have affected read speeds for NTFS volumes. Possibly it might cause the system to use unnecessary bounce buffers, but that seems unlikely to make such a large difference. Furthermore, I now believe that the commit isn't necessary at all. We'll probably get rid of the blk_queue_virt_boundary() call in the not-too-distant future. If you want to understand better how it works, you should ask people involved in maintaining the block layer. Alan Stern
