Re: FAT thrashing...

If you are appending to the end of a file, access will deteriorate as the
FAT becomes fragmented; if you need fast writes, the only way is to
pre-allocate the file.

"Jerry" <mapblast@xxxxxxxxx> wrote in message
news:1124476945.213735.146910@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> I'm working on optimizing our BSP (Xscale) and app and have run into an
> odd problem that has me stumped.
>
> The app is writing 128KB chunks of audio to disk (CF) via a customized
> driver we wrote. It's writing at a rate of about 1.1MB/sec. A logic
> analyzer instrumented to the read/write sections of the driver shows
> that the file system does a read about once a second.
>
> After running for a while, 5 to 10 minutes (depends on size/speed of
> disk), it suddenly starts doing a bunch of reads (~30) before every
> 128KB block. Putting a breakpoint in and viewing the stack I see:
>
> (etc...on down to our driver)
> FSDMGR!PartitionIoControl() line 28 + 60 bytes
> FSDMGR!FSDMGR_DiskIoControl() line 568 + 68 bytes
> FATFSD!ReadWriteDisk2() line 517 + 60 bytes
> FATFSD!ReadWriteDisk() line 258 + 44 bytes
> FATFSD!ReadVolume() line 88 + 104 bytes
> FATFSD!FindBuffer() line 1036 + 32 bytes
> FATFSD!ReadStreamBuffer() line 1236 + 96 bytes
> FATFSD!GetFAT() line 86 + 28 bytes
> FATFSD!Unpack16() line 327 + 28 bytes
> FATFSD!UnpackRun() line 540 + 32 bytes
> FATFSD!WriteStreamData() line 1019 + 8 bytes
> FATFSD!FATFSWriteFile() line 492 + 40 bytes
> FATFSD!FAT_WriteFile() line 788 + 44 bytes
> FSDMGR!FSDMGR_WriteFile() line 933 + 56 bytes
> COREDLL!xxx_WriteFile() line 80 + 36 bytes
> OUR_APP!hdRiff::Write() line 143 + 48 bytes
>
>
> We are setup to use FATFSD with cache disabled. Furthermore the files
> are created with the following flags:
>
> FILE_FLAG_WRITE_THROUGH |
> FILE_FLAG_SEQUENTIAL_SCAN |
> FILE_FLAG_NO_BUFFERING
>
> Everything works perfect up to the 5 or 10 minute mark with the FAT
> starts thrashing. If I close the file and immediately open a new one
> it will run fine for another 5 or 10 minutes.
>
> The disks aren't fragmented and this is the only disk activity going
> on.
>
> Any ideas?
>
> Thanks!
>
> -Jerry
>


.

Relevant Pages

  • Re: X-CD Roast question again please
    ... Using generic SCSI-3/mmc CD-R driver. ... Disk sub type: Medium Type A, ... ATIP start of lead in: -11318 ... writing 152 KB of pad data. ...
    (RedHat)
  • FAT thrashing...
    ... The app is writing 128KB chunks of audio to disk via a customized ... It's writing at a rate of about 1.1MB/sec. ... analyzer instrumented to the read/write sections of the driver shows ...
    (microsoft.public.windowsce.platbuilder)
  • Re: FATSystem "BUG"?
    ... Are you using the same transfer size in your block driver and filesystem ... 2)Such as CF card, SD card... ... mounted disk in "My device" under WinCE. ... I wrote an application to test R/W speed of CF card keep away from FAT: ...
    (microsoft.public.windowsce.embedded)
  • Re: About FAT16 file system cache
    ... This problem actually is possible on any standard hard disk in Windows. ... I used WinDBG to debug and found FAT file system would write the ... But my customer would like me to implement this 'sync' feature in ramdisk ... Is there any function call in driver mode like FlushFileBuffers? ...
    (microsoft.public.win32.programmer.kernel)
  • Re: FATSystem "BUG"?
    ... 2)Such as CF card, SD card... ... For example, in CF card driver, I used the stream interface(XXX_init, ... mounted disk in "My device" under WinCE. ... I wrote an application to test R/W speed of CF card keep away from FAT: ...
    (microsoft.public.windowsce.embedded)