Re: Large USB storage devices cause df to hang and cpu load reaches 100%

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/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel