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.
![[RTEMS Logo]](/images/logo.png){kind=logo}
Patch to fix exactly this problem