From: Greg Haerr <greg_at_censoft.com>
Date: Wed, 6 Nov 2002 11:35:44 -0700

: The ambition is good, but I'm not sure I understand how your solution would
look like. The caches do differ in behaviour.
: Perhaps you could illustrate with some high-level pseudo code?

I'll show you by submitting a patch that greatly cleans up the madness
in file.c, where far too much code is dedicated to keeping the
openfiles[fd].cacheoffset correct for the read/write and lseek cases.
Lseek shouldn't be mucking around performing data file i/o, other than
chasing down the cluster chain (which doesn't work, see below).

I'm working on a patch to file.c that implements sector buffering,
which should show the general idea. I can then submit a fixup
that will allow the same getblk/putblk buffering routines to be
used for FAT and directory entry buffering, as well. I promise
it will be smaller and easier to understand than the current code.

In the mean time, by reading the code, I've come up with a test
case that fails using the read (non-write) code only. I've added
this to the FAT test driver code, where it fails:

fd = open("any 1k file", 0);
lseek(fd, 513L, 0);
lseek(fd, 0L, 0); <- this seek fails

The reason this doesn't work is actually in the fat_seek()
function. Why is seeksector decremented as the first
statement? This results in looking for sector 0xffffffff from
the lseek position 0 above and fails. The seek outside the
sector boundary is required to force the cache read code
to read another sector (which shouldn't be reading anyway...)
I don't understand the fat_seek function as currently implemented.
It seems it should just check for clusternum > 0 in the for loop,
otherwise use the firstcluster.

I'll try to send the patch today.

Regards,

Greg
Received on 2002-11-06