From: Zhu Yanjun <yanjun.zhu@linux.dev>
To: Christoph Hellwig <hch@infradead.org>, Vishnu ks <ksvishnu56@gmail.com>
Cc: Song Liu <song@kernel.org>,
lsf-pc@lists.linux-foundation.org, linux-block@vger.kernel.org,
bpf@vger.kernel.org, linux-nvme@lists.infradead.org
Subject: Re: [LSF/MM/BPF TOPIC] Improving Block Layer Tracepoints for Next-Generation Backup Systems
Date: Mon, 6 Jan 2025 15:39:34 +0100 [thread overview]
Message-ID: <6c63dd3a-378d-471f-8af0-725edc3785ed@linux.dev> (raw)
In-Reply-To: <Z3uIOPxr4s09qS1X@infradead.org>
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.
next prev parent reply other threads:[~2025-01-06 14:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-01 6:34 [LSF/MM/BPF TOPIC] Improving Block Layer Tracepoints for Next-Generation Backup Systems Vishnu ks
2025-01-03 9:26 ` Christoph Hellwig
2025-01-04 0:47 ` Zhu Yanjun
2025-01-04 1:11 ` Song Liu
2025-01-04 17:52 ` Vishnu ks
2025-01-06 1:53 ` Damien Le Moal
2025-01-06 18:28 ` Vishnu ks
2025-01-06 7:37 ` Christoph Hellwig
2025-01-06 14:39 ` Zhu Yanjun [this message]
2025-01-06 18:36 ` Vishnu ks
2025-01-06 18:31 ` Vishnu ks
2025-01-06 21:19 ` Song Liu
2025-01-06 22:18 ` [Lsf-pc] " Dan Williams
2025-01-13 17:31 ` Vishnu ks
2025-02-07 2:06 ` Ming Lei
2025-02-07 11:15 ` Vishnu ks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6c63dd3a-378d-471f-8af0-725edc3785ed@linux.dev \
--to=yanjun.zhu@linux.dev \
--cc=bpf@vger.kernel.org \
--cc=hch@infradead.org \
--cc=ksvishnu56@gmail.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=song@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.