Opened 5 weeks ago
Closed 7 days 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 , 5 weeks ago
comment:4 by , 7 days ago
Milestone: | Unscheduled → R1/beta6 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Merged in hrev58332.
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.