On 06.01.25 08:37, Christoph Hellwig wrote:
On Sat, Jan 04, 2025 at 11:22:40PM +0530, Vishnu ks wrote:
1. Uses eBPF to monitor block_rq_complete tracepoint to track modified sectors
You can't. Drivers can and often do change the sector during submission
processing.
If I get you correctly, you mean, the action that **drivers often change
the sector during submission processing** will generate a lot of
tracepoint events. Thus, this will make difference on the performance of
the whole system.
If yes, can we only monitor fentry/fexit of some_important_key_function
to reduce the eBPF events? Thus this will not generate too many events
then make difference on the performance.
Zhu Yanjun
2. Captures sector numbers (not data) of changed blocks in real-time
3. Periodically syncs the actual data from these sectors based on
configurable RPO
4. Layers these incremental changes on top of base snapshots
And all of that is broken. If you are interested in this kind of
mechanism help upstreaming the blk-filter work, which has been
explicitly designed to support that.
Before that you should really undestand how block devices and
file systems work, as the rest of the mail suggested a very dangerous
misunderstanding of the basic principles.
