[LSF/MM/BPF TOPIC] Improving Block Layer Tracepoints for Next-Generation Backup Systems
Zhu Yanjun
yanjun.zhu at linux.dev
Mon Jan 6 06:39:34 PST 2025
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.
More information about the Linux-nvme
mailing list