@pitti -- that original fix in 2.6.28 timeframe appears to have been adding readahead to FAT chain scanning in fat_count_free_clusters() in the commit below:
commit 9f966be8996f2829406324c68e4c67c2d64d864b Author: OGAWA Hirofumi <email address hidden> Date: Tue Jan 8 15:32:41 2008 -0800
fat: optimize fat_count_free_clusters()
That change does not appear to have been undone specifically still appearing in the Karmic kernel.
Doing a quick test here with a 500GB USB drive I am not seeing any particularly spectacularly huge delay (this is with 2.6.31-13.43-generic):
# echo 3 >/proc/sys/vm/drop_caches # mount /dev/sdc1 /mnt; time df -h [...] /dev/sdc1 459G 45G 391G 11% /mnt
real 0m0.012s user 0m0.004s sys 0m0.000s
@pitti -- that original fix in 2.6.28 timeframe appears to have been adding readahead to FAT chain scanning in fat_count_ free_clusters( ) in the commit below:
commit 9f966be8996f282 9406324c68e4c67 c2d64d864b
Author: OGAWA Hirofumi <email address hidden>
Date: Tue Jan 8 15:32:41 2008 -0800
fat: optimize fat_count_ free_clusters( )
That change does not appear to have been undone specifically still appearing in the Karmic kernel.
Doing a quick test here with a 500GB USB drive I am not seeing any particularly spectacularly huge delay (this is with 2.6.31- 13.43-generic) :
# echo 3 >/proc/ sys/vm/ drop_caches
# mount /dev/sdc1 /mnt; time df -h
[...]
/dev/sdc1 459G 45G 391G 11% /mnt
real 0m0.012s
user 0m0.004s
sys 0m0.000s