From: David Howells <dhowells@redhat.com>
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)
Date: Tue, 06 Feb 2024 08:39:01 +0000 [thread overview]
Message-ID: <3114774.1707208741@warthog.procyon.org.uk> (raw)
In-Reply-To: <520668.1706191347@warthog.procyon.org.uk>
David Howells <dhowells@redhat.com> wrote:
> Disconnected Operation
> ======================
>
> I'm working towards providing support for disconnected operation, so that,
> provided you've got your working set pinned in the cache, you can continue to
> work on your network-provided files when the network goes away and resync 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 pinned.
>
> (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 third
> party change on reconnect. This might involve communicating via systemd
> to the desktop environment to ask the user to indicate how they'd like
> conflicts recolved.
>
> (5) A way to prompt the user to re-enter their authentication/crypto keys.
>
> (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 updated
metadata. When performing conflict resolution, userspace would need to be
able to access these in addition to the current state (local) and current
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 the
cache. That could be a number of ioctls on the target file.
- Would need a range of resolution options in userspace, not limited to keep
local, keep remote, but also the option to stash one/both somewhere. May
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 already
garbage collected, but can continue to be used as a token off which to hang
cached access rights.
David
prev parent reply other threads:[~2024-02-06 8:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-25 14:02 Roadmap for netfslib and local caching (cachefiles) David Howells
2024-01-25 14:11 ` Benjamin Coddington
2024-01-25 15:07 ` David Howells
2024-01-25 19:28 ` Benjamin Coddington
2024-01-25 15:22 ` Gao Xiang
2024-01-25 16:29 ` Jeff Layton
2024-01-25 17:23 ` Christian Brauner
2024-02-06 8:39 ` David Howells [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3114774.1707208741@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=brauner@kernel.org \
--cc=ceph-devel@vger.kernel.org \
--cc=esandeen@redhat.com \
--cc=jlayton@kernel.org \
--cc=linux-afs@lists.infradead.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=samba-technical@lists.samba.org \
--cc=v9fs@lists.linux.dev \
--cc=willy@infradead.org \
--cc=xiang@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).