[NTLUG:Discuss] Disk I/O timings.

[Bug Hunter]

  You are correct in that the problem is the linux file caching.  

  All available memory is used for file cache.

  Hard drives now have RAM caching, and the size of the cache is usually
reported by the drive at BIOS boot time, and is available via dmesg.  It
is typically a track-at-a-time cache, which can give very good results for
a un-fragmented drive.

  What are you after?  Worst case?

bug

On Tue, 4 Dec 2001, Steve Baker wrote:

> 
> This is driving me nuts...
> 
> I have a Linux program that does (essentially) this:
> 
>     open() a file for reading from a local ext2 file system on an IDE drive.
> 
>     fstat() in order to determine it's length
> 
>     mmap() to map it onto a chunk of address space
> 
>     cycle through that array reading each element and computing a checksum
> 
>     munmap() the address space
> 
>     close() the file.
> 
> Can anyone tell me when in that sequence of operations the transfer of
> the data from the disk drive actually occurs?  (Presuming the file is not
> in cache).
> 
> I've had a hard time measuring when it occurs. On one machine it appears
> to be consuming a dozen milliceonds or more in the 'open' command and on
> another machine, I see a similar amount of time being consumed when I cycle
> through the array reading it.   I could believe the kernel would either
> speculatively load the file into cache when it's 'open()'ed *or* wait until
> the page fault from accessing the mmap'ed array triggered the first actual need
> to know the contents of the file....but which is it?
> 
> The thing that makes measuring this hard (in my *VERY* large and complex
> real application) is that I'm actually reading several files in parallel
> using this technique - and also the caching of files into main memory
> by the kernel makes all my testing highly non-repeatable.  I run my test once
> and see long delays in file I/O - but the next time I run it, the file is
> (presumably) still in cache so there are no significant delays in reading
> it.
> 
> Is there a means to ask the kernel to erase the contents of it's disk cache?
> 
> I thought of un-mounting the drive that the file is on and re-mounting it - that
> ought to invalidate the kernel's cache - but it's very inconvenient.  Is there a
> better way?
> 
> I also realise that there is a RAM cache on the disk drive itself - does that
> ever get filled speculatively by the drive (or the kernel) ?
>