block_cache: enable length parameter in get_etc()

[Jim906]

It appears that the function signatures of block_cache_get(_writable)_etc were originally meant to allow a file system to request a run of consecutive blocks. However, the length parameter has no effect; the functions always behave as if one block was requested.

I experimented with a change to the block cache that takes the length parameter into account and attempts to read all requested blocks in a single disk read. It looks like this can be done without adding much overhead that would slow down single-block requests.

The FAT driver could be modified to take advantage of this capability, particularly to reduce the number of disk reads when mounting a partition (mounting involves reading the entire FAT table, which can take time on a large partition). I don't know if other file systems could also benefit.

I could work on a patch that implements this, if it sounds like a good idea to the Haiku maintainers.

[waddlesplash]

These parameters can't work properly, so I think they should just be removed, and I did that in hrev58247.

However, I think your suggestion does have merit. A similar change in the BFS disk iteration code should also speed things up. To that end I think we should add a block_cache_prefetch method, which loads (or schedules a load) of a contiguous run of blocks. That sounds like it should handle this case nicely.