Received-SPF: pass (google.com: domain of linux-nfs+bounces-711-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
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: <8b9413cc37a231a97059c7d028d404ab35363764.camel@kernel.org>
References: <8b9413cc37a231a97059c7d028d404ab35363764.camel@kernel.org> <20231213152350.431591-1-dhowells@redhat.com> <20231213152350.431591-38-dhowells@redhat.com>
To: Jeff Layton <jlayton@kernel.org>
Cc: dhowells@redhat.com, Steve French <smfrench@gmail.com>,
    Matthew Wilcox <willy@infradead.org>,
    Marc Dionne <marc.dionne@auristor.com>,
    Paulo Alcantara <pc@manguebit.com>,
    Shyam Prasad N <sprasad@microsoft.com>, Tom Talpey <tom@talpey.com>,
    Dominique Martinet <asmadeus@codewreck.org>,
    Eric Van Hensbergen <ericvh@kernel.org>,
    Ilya Dryomov <idryomov@gmail.com>,
    Christian Brauner <christian@brauner.io>, linux-cachefs@redhat.com,
    linux-afs@lists.infradead.org, linux-cifs@vger.kernel.org,
    linux-nfs@vger.kernel.org, ceph-devel@vger.kernel.org,
    v9fs@lists.linux.dev, linux-fsdevel@vger.kernel.org,
    linux-mm@kvack.org, netdev@vger.kernel.org,
    linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 37/39] netfs: Optimise away reads above the point at which there can be no data
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1075372.1703004999.1@warthog.procyon.org.uk>
Date: Tue, 19 Dec 2023 16:56:39 +0000
Message-ID: <1075373.1703004999@warthog.procyon.org.uk>

Jeff Layton <jlayton@kernel.org> wrote:

> >  (4) On local truncation up, we don't change zero_point.
> > 
> 
> The above seems odd, but I guess the assumption is that if there are any
> writes by a 3rd party above the old zero point, that that would cause an
> invalidation?

All truncating up does is extend the region from which reading would return
zeros, so it doesn't affect the zero_point.

If a third party interferes, then we have to invalidate the local caches and
reset zero_point to the EOF.  But if a third party is writing to the file at
the same time as you without both of you using locking or exclusive direct
writes, your data is probably screwed anyway...

Something cifs and ceph can use leasing to make this work; afs uses the data
version number, notifications and the principle that you should use file
locks.

David