Low efficiency for libfat in large file, how to improve it?

I'm developing a new app -- RealWnW to restore NAND image. I know there is BootMii now, and it seems nobody need another NAND writer. I write it for fun and also due to BootMii still incompatible with my SDHC.

I do many pre-programming analysis to prevent things go wrong. This requires frequently calling fseek() +fread() to NAND image of (512+16) MB in size. It seems libfat does not cache enough FAT entries so as to be very very low efficiency for fseek() in large file. To solve it, first I tried to keep tracking of the file pointer by myself and call fseek() with SEEK_CUR instead of SEEK_SET. This helps little. I guess even using SEET_CUR also cause the libfat to calculate absolute pointer and seek from file beginning. Then I split image file as 16 smaller sub images. This greatly reduces analysis time from 2~3 hrs to only 20 mins.

Anyway to improve fseek() efficiency w/o spliting files? For example, to increase FAT tables cache or to patch libfat to do relative seek calculation but not absolute seek calculation.

--------------------------------------------------------------------------------------------------------
Edit 1:
I think I've found some related function. I should use fatMount() with larger cache instead of fatMountSimple() to try if it helps. Hope the libfat keep more cache for FAT entries than data contents.
--------------------------------------------------------------------------------------------------------
Edit 2:
How to know the default cache size so I can increase it to try?



Edited 2 time(s). Last edit at 05/30/2009 09:24AM by pcfree.

First question, are you trying the latest libfat from devkitpro SVN?

I used Win32 devkitProUpdater 1.5.0 released at 9 May 2009 to install my tools chain. I guess It should be new enough.

No. Download, make, and make install the latest libogc and libfat from SVN.

Thank! The newest SVN greatly improves FAT access. However, I still have to split image file because the new SNV also greatly reduces smaller sub image access.

Some results for my analysis time are provided as reference:
old Lib + one large image: too long and I break it, estimated 39min*4 = 156mins
old Lib + 16 subimages + tracking file pointer = 850 secs.
new Lib + one large image = 1017 secs.
new Lib + 16 subimages + tracking file pointer = 116 secs.