Unnecessary read from device driver in case we have READ_AHEAD entry in CACHE

[Oleg]

When we turn on read ahead feature and read blocks in sequence, the code does not use already pre-read blocks and start reading them from driver, which might reduce performance.

According to rtems_bdbuf_get_buffer() function, it can return a buffer in READ_AHEAD state that keeps valid data, and that should be returned by rtems_bdbuf_read() function, BUT instead of this rtems_bdbuf_read() initiates a new data transfer!

The problem is because we should have checked if a block is in either CACHED, MODIFIED, or READ_AHEAD state, but right now the code checks if a block is in CACHED or MODIFIED states only.

Actually I can't understand why READ_AHEAD state exists, it is actually not a state but rather attribute, because all READ_AHEAD buffers are the same as buffers in CACHED state (i.e. keep valid data), but the difference is that READ_AHEAD buffers are in ready list, and CACHED not there.

I.e. I believe that READ_AHEAD state should be removed and use a single CACHED state for it, but the way how it is handled will be indirectly show that it is read ahead, i.e. javing a CACHED buffer in ready list means that it was read ahead. I do not see any speciality or usefulness for READ_AHEAD state, but this is the matter of another Bug.

Simple test:

• enable read ahead in the image;
• read block #N (as the result this will read ahead some more blocks - depending on the configuration);
• read block #N+1 (there should be no access to the media), BUT right now there is access.

[Oleg]

Patch to fix exactly this problem

[Oleg]

The initial problem seems to be fixed. At least your re-worked version does not seem to have this bug.