Re: [PATCH 0/4] ksmbd: implement Continuously Available (CA) share support

[Yunseong Kim]

Hi Namjae,

On Thu, 27 Aug 2026 16:54:30 +0900 Namjae Jeon <linkinjeon@xxxxxxxxxx> wrote:

> On Mon, Aug 24, 2026 at 9:56 AM Yunseong Kim <yunseong.kim@xxxxxxxx> wrote:
> >
> > Enable the Continuously Available (CA) share infrastructure in ksmbd,
> > allowing SMB clients to request and use persistent handles on configured shares.
> >
> > Background
> > =====
> >
> > KSMBD already has a complete in-memory durable handle v1/v2
> > implementation including the persistent handle data model
> > (fp->is_persistent), protocol parsing (DH2Q with
> > SMB2_DHANDLE_FLAG_PERSISTENT), and reconnect validation (DH2C). However,
> > the server never advertises SMB2_GLOBAL_CAP_PERSISTENT_HANDLES or sets
> > SMB2_SHARE_CAP_CONTINUOUS_AVAILABILITY, making this code path unreachable
> > by clients.
> >
> > Per MS-SMB2, a client can only request a persistent handle on a share
> > that advertises SMB2_SHARE_CAP_CONTINUOUS_AVAILABILITY. This creates a
> > chicken-and-egg: we cannot test persistent handles without first
> > advertising the CA capability.
> This looks like a useful first step, but I don't think it provides CA
> support yet.

I agree, I was considering the validation aspects when I wrote this
v1 draft patch series.

> The handle state is still kept only in memory. The existing code can
> reconnect a durable handle after a connection or session loss while
> the server is still running, but that state is lost when ksmbd or the
> kernel is restarted. The server therefore can not reconstruct the open
> from the persistent-id or CreateGuid.
 
Thank you for summarizing this information.

> I think this should be implemented in two stages:

> 1. Standalone CA: add a local crash-safe journal/state store and
> recover the open state after a server restart, including
> persistent-handle, lease/oplock, ownership, and replay state.

Okay, I've been starting "Standalone CA" supports for the next v2 patch
series.

> 2. Cluster CA: make the persistent open state available to the node
> that takes over the share, then add cluster ownership management,
> stale-node fencing, and cross-node failover support.

After the standalone version has been verified and merged, I will work on it.

> Standalone CA should be implemented and validated first. Cluster CA,
> including cross-node failover, should then be built on top of it.
> Until standalone recovery is available, advertising the
> persistent-handle and CA capabilities seems premature. It seems that
> many updates will be needed to ksmbd-tools when implementing Cluster
> CA.

Understood, making a solid foundation first.

> Thanks.
> 

Thank you!

Best regards,
Yunseong