Opened 2 months ago

Closed 6 weeks ago

#19186 closed enhancement (fixed)

block_cache: enable length parameter in get_etc()

Reported by: Jim906 Owned by: nobody
Priority: normal Milestone: R1/beta6
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

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.

Change History (4)

comment:1 by waddlesplash, 2 months ago

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.

comment:2 by Jim906, 2 months ago

All right, I will try adding block_cache_prefetch.

comment:4 by waddlesplash, 6 weeks ago

Milestone: UnscheduledR1/beta6
Resolution: fixed
Status: newclosed

Merged in hrev58332.

Note: See TracTickets for help on using tickets.