Thank you for pointing out these critical issues: 1. The sector tracking approach is fundamentally flawed because drivers can modify sectors during submission 2. I'll look into the blk-filter work as it seems to be designed specifically for this use case Could you point me to resources about the blk-filter work? I'd like to understand it better and potentially contribute to its upstream efforts. You're right that I need a better understanding of block devices and filesystem fundamentals. Could you recommend any specific documentation or reading materials on these topics? On Mon, 6 Jan 2025 at 13:07, Christoph Hellwig <hch@xxxxxxxxxxxxx> 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. > > > 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
