Received-SPF: pass (google.com: domain of linux-kernel+bounces-54509-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley
	Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United
	Kingdom.
	Registered in England and Wales under Company Registration No. 3798903
From: David Howells <dhowells@redhat.com>
In-Reply-To: <520668.1706191347@warthog.procyon.org.uk>
References: <520668.1706191347@warthog.procyon.org.uk>
Cc: dhowells@redhat.com, Gao Xiang <xiang@kernel.org>,
    Jeff Layton <jlayton@kernel.org>,
    Christian Brauner <brauner@kernel.org>,
    Matthew Wilcox <willy@infradead.org>,
    Eric Sandeen <esandeen@redhat.com>, v9fs@lists.linux.dev,
    linux-afs@lists.infradead.org, ceph-devel@vger.kernel.org,
    linux-cifs@vger.kernel.org, samba-technical@lists.samba.org,
    linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
    linux-kernel@vger.kernel.org
Subject: Re: Roadmap for netfslib and local caching (cachefiles)
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3114773.1707208741.1@warthog.procyon.org.uk>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 06 Feb 2024 08:39:01 +0000
Message-ID: <3114774.1707208741@warthog.procyon.org.uk>

David Howells <dhowells@redhat.com> wrote:

> Disconnected Operation
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =

> I'm working towards providing support for disconnected operation, so tha=
t,
> provided you've got your working set pinned in the cache, you can contin=
ue to
> work on your network-provided files when the network goes away and resyn=
c the
> changes later.
> =

> This is going to require a number of things:
> =

>  (1) A user API by which files can be preloaded into the cache and pinne=
d.
> =

>  (2) The ability to track changes in the cache.
> =

>  (3) A way to synchronise changes on reconnection.
> =

>  (4) A way to communicate to the user when there's a conflict with a thi=
rd
>      party change on reconnect.  This might involve communicating via sy=
stemd
>      to the desktop environment to ask the user to indicate how they'd l=
ike
>      conflicts recolved.
> =

>  (5) A way to prompt the user to re-enter their authentication/crypto ke=
ys.
> =

>  (6) A way to ask the user how to handle a process that wants to access =
data
>      we don't have (error/wait) - and how to handle the DE getting stuck=
 in
>      this fashion.

Some further thoughts stemming from a discussion with Willy:

 - Would need to store the pre-disconnection metadata as well as any updat=
ed
   metadata.  When performing conflict resolution, userspace would need to=
 be
   able to access these in addition to the current state (local) and curre=
nt
   state (server).

 - Would need the ability to include extra stats, such as the AFS data
   version, that are used for cache coherency management.

 - Would need to provide an API by which userspace can access both states =
of
   the data, possibly including the original data if we still have it in t=
he
   cache.  That could be a number of ioctls on the target file.

 - Would need a range of resolution options in userspace, not limited to k=
eep
   local, keep remote, but also the option to stash one/both somewhere.  M=
ay
   also need to provide app-specific resolvers - merging git trees for
   example, but also what do you do about sqlite databases, say?

 - There may be bulk changes that the user would want to resolve in bulk,
   perhaps by "everything in the subtree" or pattern matching rules,
   e.g. "disard all .o files" or "take the .o file matching the newest .c =
file
   in the same directory".

 - May need to change how expired keys are handled so that they aren't alr=
eady
   garbage collected, but can continue to be used as a token off which to =
hang
   cached access rights.

David