Thanks Ming for the insightful suggestion about struct_ops pairs for bio handling. Moving these operations to eBPF aligns perfectly with the goal of keeping non-essential business logic outside the kernel. As mentioned previously, I've open-sourced our implementation (blxrep) which demonstrates this approach. While simple in implementation, it's proven effective for capturing incremental changes on data disks with sync frequencies above 3 minutes: BPF implementation: https://github.com/xmigrate/blxrep/blob/main/bpf/trace-blocks.c Documentation: https://blxrep.xmigrate.cloud/ Your suggestion about generic bio/bvec kfuncs is particularly interesting. Would you be open to providing feedback on our current BPF program structure, particularly regarding how we could better leverage these proposed bio handling capabilities? I would also like to hear what others think about this approach. Thanks, Vishnu KS On Fri, 7 Feb 2025 at 07:36, Ming Lei <ming.lei@xxxxxxxxxx> wrote: > > On Mon, Jan 13, 2025 at 11:01:30PM +0530, Vishnu ks wrote: > > Thanks everyone for the detailed technical feedback and clarifications > > - they've been extremely valuable in understanding the fundamental > > challenges and existing solutions. > > > > I appreciate the points about md-cluster and DRBD's network RAID > > capabilities. While these are robust solutions for network-based > > replication, I'm particularly interested in the point-in-time recovery > > capability for scenarios like ransomware recovery, where being able to > > roll back to a specific point before encryption occurred would be > > valuable. > > > > Regarding blk_filter - I've been exploring it since it was mentioned, > > and it indeed seems to be the right approach for what we're trying to > > achieve. However, I've found that many of our current requirements can > > actually be implemented using eBPF without additional kernel modules. > > I plan to create a detailed demonstration video to share my findings > > with this thread. Additionally, I'll be cleaning up and open-sourcing > > our replicator utility implementation for community feedback. > > > > I would very much like to attend the LSF/MM/BPF summit to discuss > > these ideas in person and learn more about blk_filter and proper block > > layer fundamentals. Would it be possible for someone to help me with > > an invitation? > > If one pair of bpf struct_ops are added for attaching to submit_bio() > and ->bi_end_io() in bio_endio(), lots of cases can be covered: > > - blk filter > > - bio interposer > > - blk-snap > > - easier IO trace > > ... > > Then both bio and request based devices can be covered. > > It shouldn't be hard to figure out generic bio/bvec kfuncs for helping block IO > bpf prog to do more valuable things & fun. > > Thanks, > Ming > -- Vishnu KS, Opensource contributor and researcher, https://iamvishnuks.com
