[Devel] [PATCH v3 vz9/vz10] dm-ploop: fallback to kvmalloc for large bvec allocations

Pavel Tikhomirov ptikhomirov at virtuozzo.com
Fri Oct 24 08:40:52 MSK 2025



On 10/22/25 23:20, Vasileios Almpanis wrote:
> When handling multiple concurrent dm-ploop requests, large bio_vec arrays
> can be allocated during request processing. These allocations are currently
> done with kmalloc_array(GFP_ATOMIC), which can fail under memory pressure
> for higher orders (order >= 6, ~256KB). Such failures result in partial or
> corrupted I/O, leading to EXT4 directory checksum errors and read-only
> remounts under heavy parallel workloads.

I don't fully like this approach. According to the commit message, the 
allocation error path leads to corruption. And instead of fixing the 
corruption on this error path we try to workaround it by eliminating 
this error path through delaying the allocation.

What if ploop_split_pio_to_list will fail (another error path in the 
same stack) will it lead to the corruption again?

In ideal world the error should be reported to the "user" (ext4) the way 
it understands exactly what data to expect on disk. Now we see that ext4 
reports invalid checksums, that means AFAIU that errors were not 
reported to it correctly.

What I'm trying to say is that, maybe, making the allocation work is 
only a part of the solution, but not the whole solution.

-- 
Best regards, Pavel Tikhomirov
Senior Software Developer, Virtuozzo.



More information about the Devel mailing list