Skip to content

data_prealloc_blocks_min mount+sysfs option.#293

Open
aversecat wants to merge 1 commit intomainfrom
auke/data_prealloc_min
Open

data_prealloc_blocks_min mount+sysfs option.#293
aversecat wants to merge 1 commit intomainfrom
auke/data_prealloc_min

Conversation

@aversecat
Copy link
Copy Markdown
Contributor

Adds an accompanying option to set a data preallocation minimum threshold value. The value can be set through sysfs or at mount time.

data_prealloc_blocks_min cannot be larger than data_prealloc_blocks, and this is enforced. This should be fine for all common use cases where the _min option is expected to be less than 2048, the default of data_prealloc_blocks.

Extra test cases are added to validate bad mount option values and sysfs value writes. As well as tests that validate that the minimum threshold is set and honored as expected.

Preallocation scales with scoutfs_get_inode_onoff() online values, so that new extents double the online size every allocation until it reaches data_prealloc_blocks. The _onoff() value is only fetched once if possible.

Adds an accompanying option to set a data preallocation minimum
threshold value. The value can be set through sysfs or at mount
time.

data_prealloc_blocks_min cannot be larger than data_prealloc_blocks,
and this is enforced. This should be fine for all common use
cases where the _min option is expected to be less than 2048,
the default of data_prealloc_blocks.

Extra test cases are added to validate bad mount option values and
sysfs value writes. As well as tests that validate that the
minimum threshold is set and honored as expected.

Preallocation scales with scoutfs_get_inode_onoff() online values,
so that new extents double the online size every allocation until
it reaches data_prealloc_blocks. The _onoff() value is only
fetched once if possible.

Signed-off-by: Auke Kok <auke.kok@versity.com>
@aversecat aversecat requested a review from zabbo April 13, 2026 18:32
@zabbo
Copy link
Copy Markdown
Collaborator

zabbo commented Apr 13, 2026

I guess my question here is why we need the mount option. Instead of ramping up in powers of two to the min, it'll allocate single blocks. 2047 extents vs 11 extents seems like a pretty exciting difference. Why not always ramp up based on whatever combination of online blocks and file size gets whatever behaviour we're after?

@aversecat
Copy link
Copy Markdown
Contributor Author

That's a good point, and, it will hugely simplify this patch. The ramping up by itself should already do exactly what we'd want.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants