Thank you for the suggestion about fentry/fexit monitoring. However, as Christoph pointed out, the fundamental issue isn't just about performance or number of events - it's that the sector numbers themselves can be modified by drivers during submission and I am not sure if this is notified back to the kernel somehow. On Mon, 6 Jan 2025 at 20:09, Zhu Yanjun <yanjun.zhu@xxxxxxxxx> wrote: > > 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. > -- Vishnu KS, Opensource contributor and researcher, https://iamvishnuks.com
