Sergey Vlasov wrote: > On Tue, Jul 31, 2007 at 11:08:37PM +0100, Kostas Peletidis wrote: > >> Branden Sletteland wrote: >> >>> I have also noticed this delay and have through instrumenting code >>> have found that every block in the device gets read in. I never >>> checked if it was something in the df, filesystem, SCSI, or USB >>> subsystems that was causing this. I am usually doing df on USB >>> storage devices formated as FAT 32 w/ and w/o LBA. >>> >>> Branden >>> >>> >>> >> Thanks for your reply Branden. This explains why df would delay for a >> whole minute to terminate normally with a 500GB usb disk attached and >> only for a second or two with a 512MB usb stick attached. Btw both are vfat. >> >> This brings another question though: Why read every single block during >> the first run of df after the partition is mounted? Obviously buffering >> 500GB for fast access is currently out of the question so could it be >> the case that some sanity check was going on? >> > > Probably the commit 28ec039c21839914389975b896160a815ffd8b83 is the > culprit: > > fat: don't use free_clusters for fat32 > > It seems that the recent Windows changed specification, and it's > undocumented. Windows doesn't update ->free_clusters correctly. > > This patch doesn't use ->free_clusters by default. (instead, add > "usefree" > for forcing to use it) > > Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]> > Cc: Juergen Beisert <[EMAIL PROTECTED]> > Cc: Andreas Schwab <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > You can add "usefree" to mount options - it will restore the old > behavior (which can apparently lead to wrong free space reports after > the disk has been used by some Windows versions). Without "usefree" > the vfat code in 2.6.22 will read the whole FAT to count free clusters > on the filesystem. > I added "usefree" in the /etc/fstab options and the problem went away. When I omitted the "usefree" option the delay occured as expected.
Well done Sergey and thanks for the solution! I don't know why reading only the FAT slowed things down that much but it looks like things are back to normal now. Many thanks to everyone involved! :-) This is indeed not a USB bug and I guess this is not a kernel bug at all since the patch was added for compatibility purposes. I wonder though if this needs to be investigated more by the fs people on the grounds that it has an impact on usability. Regards, Kostas ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
