From: Greg Haerr <greg_at_censoft.com>
Date: Mon, 4 Nov 2002 11:18:06 -0700

> I personally think a redesign where _all_ buffers are kept at a layer
> just above the ata_{read,write}_sector layer and allowing the file
> open/read/write code to access them would make things alot simpler, and
> tunably smaller.

> I disagree. There is good reason for each of the three separate buffers:

I think you misunderstood my idea - I'm not suggesting that the file i/o
buffer take place in any buffer mechanism related to mp3 playing.
Instead, I'm suggesting a design change which cleans up the code
significantly of special cases, like the longname buffer saving. Let me
try to explain again, using the numbered cases in your reply:

> 1) Buffering one sector per open file means we can always provide
byte-for-byte file access within the last accessed sector without accessing the
disk. This is the same model buffered i/o works in most operating systems

1. Yes of course we want to keep a sector buffer for each open file, for
head and tail bytes and byte-for-byte access. When file reads/writes are
requested that map to sector boundaries, the buffer mechanism is skipped.
If the sector buffers were kept by a lower layer, then the special code
in file.c wouldn't be required that handles locally declared buffers.

> 2) Buffering the two last read directory sectors is vital for long filename
parsing, since a single long filename can span three (!) directory sectors.

2. Yes we have to buffer recently used FAT sectors for longname handling.
If the buffer handling were at a lower layer, the special routine
cache_fat_sector
wouldn't be required, and the same mechanism could be used to buffer
FAT sectors and byte-by-byte sectors.

> 3) Caching the most recently used FAT sectors means we obtain very fast access
to cluster chain information, which in turn speeds up disk reads and writes
substantially.


3. Exactly - of course we need to buffer the FAT sectors. I'm suggesting we
use a common mechanism that allows any sector to be buffered, this
takes away the "special" routines at the 1) fat reading, 2) longname handling,
and 3) file reading layers. It's simpler, that's all. And another benefit
would
automatic buffering of the root directory, without increasing static
data allocations.


>4) Combining these three buffers into a regular i/o buffer would slow overall
performance down, because the regular very big mp3 file reads will fill the
buffer every time.


4) The lower layer buffer mechanism would skip buffering, unless requested
explicitly to buffer with a flag, on multi-sector reads/writes and reads/writes
on a sector boundary. This allows maximal performance for all of our i/o cases.
If you actually analyze and look at the current disk i/o behavoiur, you will
see that we're not running optimally now - many dir sectors are physically
re-read right after writing, slowing down performance. (thanks to Bjorn's
simulator this is easy to see...) We need a lower-layer cache or we're
_not_ going to get best performance.

WRT read-access updating, I wasn't trying to suggest that we have to have
it, but rather than the current design doesn't handle it well. For instance,
we have a "special" fat_closewrite entry point that should be just a
fat_close entry point, handling read or write closing. It could be turned
on or off at compile time by somebody that might want to use it, as people
have already responded with "we might make use of it to ..."

Hopefully this clarifies my idea. I'm willing to code all this up as well.

Regards,

Greg
Received on 2002-11-04