From: Christoph Hellwig <hch@infradead.org>
To: Trond Myklebust <trondmy@hammerspace.com>
Cc: "dan.aloni@vastdata.com" <dan.aloni@vastdata.com>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"sagi@grimberg.me" <sagi@grimberg.me>
Subject: Re: [PATCH] nfs: add 'noextend' option for lock-less 'lost writes' prevention
Date: Wed, 19 Jun 2024 22:26:24 -0700 [thread overview]
Message-ID: <ZnO9gBD4-P1bsEmN@infradead.org> (raw)
In-Reply-To: <5366ff2a4f731dbd93a56e109d6809a5348cf080.camel@hammerspace.com>
On Wed, Jun 19, 2024 at 02:15:16PM +0000, Trond Myklebust wrote:
> BTW: We've been asked about the same issue from some of our customers,
> and are planning on solving the problem by adding a new per-file
> attribute to the NFSv4.2 protocol.
>
> The detection of that NOCACHE attribute would cause the client to
> automatically choose O_DIRECT on file open, overriding the default
> buffered I/O model. So this would allow the user or sysadmin to specify
> at file creation time that this file will be used for purposes that are
> incompatible with caching.
Can we please come up with coherent semantics for this on the fsdevel
list? We've had quite a few requests for something similar for local
file systems as well. The important fine points are things like keeping
the cache coherent if there already is one and only bypassing it
for new data (or alternatively writing it back / invalidating it
beforehand), and the lack of alignment requirements that O_DIRECT
usually has (although that doesn't apply to NFS).
next prev parent reply other threads:[~2024-06-20 5:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-18 15:33 [PATCH] nfs: add 'noextend' option for lock-less 'lost writes' prevention Dan Aloni
2024-06-18 18:59 ` Trond Myklebust
2024-06-19 8:37 ` Sagi Grimberg
2024-06-19 14:15 ` Trond Myklebust
2024-06-19 14:31 ` Sagi Grimberg
2024-06-20 5:27 ` Christoph Hellwig
2024-06-20 6:41 ` Sagi Grimberg
2024-06-20 5:26 ` Christoph Hellwig [this message]
2024-06-19 5:44 ` Christoph Hellwig
2024-06-19 13:33 ` Trond Myklebust
2024-06-19 18:03 ` Trond Myklebust
2024-06-20 5:13 ` hch
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=ZnO9gBD4-P1bsEmN@infradead.org \
--to=hch@infradead.org \
--cc=dan.aloni@vastdata.com \
--cc=linux-nfs@vger.kernel.org \
--cc=sagi@grimberg.me \
--cc=trondmy@hammerspace.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.