On Thu, Jun 11, 2026 at 1:59 PM Leon Romanovsky <leon@kernel.org> wrote:
>
> On Wed, May 27, 2026 at 02:44:08PM +0200, Haris Iqbal wrote:
> > On Tue, May 12, 2026 at 12:34 PM Leon Romanovsky <leon@kernel.org> wrote:
> > >
> > > On Tue, May 05, 2026 at 09:46:12AM +0200, Md Haris Iqbal wrote:
> > > > Following a conversation with Bart yesterday, I am sending the RMR+BRMR
> > > > code through patch for easier review.
> > > >
> > > > The patches apply over the for-next branch of the block tree over commit
> > > > 07dfa981ca3
> > > >
> > > > For context,
> > > > RMR (Reliable Multicast over RTRS) is a kernel module that provides
> > > > active-active block-level replication over RDMA. It guarantees delivery
> > > > of IO to a group of storage nodes and handles resynchronization of data
> > > > directly between storage nodes without involving the compute client.
> > > >
> > > > BRMR (Block device over RMR) sits on top of RMR and exposes a standard
> > > > Linux block device (/dev/brmrX) backed by an RMR pool. Together, RMR and
> > > > BRMR provide a single-hop replication and resynchronization solution for
> > > > RDMA-connected storage clusters.
> > > >
> > > > My session is on Wednesday, at 12 in the storage room (Istanbul).
> > >
> > > To summarize the discussion:
> > >
> > > 1. Move as much logic as possible into the block layer; RDMA should serve
> > > strictly as a transport.
> > > 2. Identify another in‑kernel user of this functionality, and add support for
> > > it if required. At least accommodate potential users elsewhere in the
> > > kernel.
> >
> > Thanks for the summary Leon.
> >
> > The main logic which handles multicast/replication legs, missed I/O
> > tracking, re-synchronization, etc are the core parts of RMR.
> > If we move those to a separate module, there won't be much left in
> > RMR. RMR already uses RTRS from the RDMA subsystem as transport.
> >
> > Having said that, I am not against moving RMR out of the RDMA layer.
> > It can serve as a reliable replication service/library for any other
> > user in the kernel to use.
> > Which subsystem (block or something else) would be a better fit then,
> > can be discussed.
> >
> > PS: Would this be a good candidate for a session/discussion in the upcoming LPC?
>
> Probably yes.
>
> Thanks
Thanks Leon. I'll submit the abstract through the portal.
Do you think the topic is better suited towards Refereed track or Kernel Summit?
>
> >
> > >
> > > Thanks