[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