On 2/26/24 19:04, Christoph Hellwig wrote:
On Sat, Feb 24, 2024 at 04:41:43PM +0800, Heming Zhao wrote:
maybe I misunderstood your meaning, do you mean: you don't like the design of the bitmap, and you hope/plan to drop it?
bitmap is a journal-like stuff. we could get an idea from filesystem journal, just write data status to the bitmap area, rather than managing it in kernel memory. with this idea, writing data protection may involve more simpler code, the replay will become more complex.
The main problem with the dm-bitmap code is the way it does I/O. Using
->bmap to try to map blocks ahead is cumbersome, and unsafe in many
ways. If you want to keep the MD bitmap code alive someone needs to
rewrite it to go through the file systems read_iter/write_iter ops
and do direct I/O.
Thank you for your explanation, I understand your meaning. It looks the
code changes include userspace (mdadm) & kernelspace (md module) changes.
mdadm should open a file with dio, kernel should call read_iter/write_iter
ops for IOs.
From my experience, I have never seen any SUSE customer using kernel
to manager bitmap under external mode (intel VROC is another topic).
This job has a very low priority from my side.
Thanks,
Heming
