在 2024/5/4 08:57, Anand Jain 写道:
On 5/4/24 06:23, Qu Wenruo wrote:
在 2024/5/3 21:55, Anand Jain 写道:
[...]
+int find_prealloc(struct blk_iterate_data *data, int index, bool
*prealloc)
This function is called for every file extent we're going to create.
I'm not a big fan of doing so many lookup.
My question is, is this the only way to determine the flag of the
data extent?
My instinct says there should be a straight forward way to determine
if a file extent is preallocated or not, just like what we do in our
file extent items.
Thus during the ext2fs_block_iterate2(), there should be some way to
tell if a block is preallocated or not.
Unfortunately, the callback doesn't provide the extent flags. Unless,
I miss something?
You're right, the iterator interface does not provide any extra info.
And I also checked the kernel implementation, they have extra
ext4_map_blocks() to do the resolve, and then ext4_es_lookup_extent()
to determine if it's unwritten.
So I'm afraid we have to go this solution.
Meanwhile related to the implementation, can we put the prealloc flat
into blk_iterate_data?
So that we can handle different fses' preallocated extents in a more
common way.
I initially thought so, but is blk_iterate_data::num_blocks always
equal to extent::e_len in all file data extent situations mixed
with hole and unwritten combinations? If not, then the flag might
not be appropriate there, as it doesn't apply to the entirety of
blk_iterate_data::num_blocks.
I do not think we need @num_blocks to match extent_len.
We're already doing some kind of merge inside block_iterate_proc(), and
if we find previous extent flag doesn't match the current one, we just
need to submit the previous one.
Although I also believe we need some better abstraction for the common code.
The current one doesn't explain everything well for things parameters
like disk_block/file_block.
Thanks,
Qu
Thanks, Anand
Thanks,
Qu
