From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A63B9C46CCD for ; Tue, 19 Dec 2023 16:56:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 01EB06B007E; Tue, 19 Dec 2023 11:56:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EEBDB6B0080; Tue, 19 Dec 2023 11:56:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D8B686B0082; Tue, 19 Dec 2023 11:56:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id BFDC36B007E for ; Tue, 19 Dec 2023 11:56:52 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 9A7BE160C31 for ; Tue, 19 Dec 2023 16:56:52 +0000 (UTC) X-FDA: 81584172264.18.71AAEBA Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf24.hostedemail.com (Postfix) with ESMTP id A3DD8180003 for ; Tue, 19 Dec 2023 16:56:49 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=BJAq7D74; spf=pass (imf24.hostedemail.com: domain of dhowells@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=dhowells@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1703005009; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=B719XTWiXIHllaEXvsXPz/Q4Bs162RLSRke3FIDQ97A=; b=KEzrq/2VavsNISEKRJ4F74rzS4wMmRzY6OUega112j8K+HWB/rjd5t0Qf11440GceliaL/ 17a1de2w7XwDRdlam0drNcuDWXHBnQFeqWHSh1tk46bVRnCYbCdYxcEP7ypFZ/VqVsvEgy cKrOY4ulGjO2fzcfva6GITu294AolhE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703005009; a=rsa-sha256; cv=none; b=l9qyWKxW5Fq9RN4ruHRbOz9I7CSzm8iaKv4F6QQwzPLaVG9FGC6+Dg99StzN5PWLld+zFh knsL/y8sIccVX3H6+5RItWeMakDgKyEsu81Muu7Z39K3o7SD+F4zV8PybilEwtnA4Lv8DH GV4fTsWYhJphH3k9XS8tsBKvgiANNqU= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=BJAq7D74; spf=pass (imf24.hostedemail.com: domain of dhowells@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=dhowells@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1703005008; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=B719XTWiXIHllaEXvsXPz/Q4Bs162RLSRke3FIDQ97A=; b=BJAq7D74150Mq0MJ3MO2Y0o9pfEp5e+H8LygRQmqLLpgWQZ9nrVxGYtRNFHdNBc1b3Ik51 wWnbGfEtjGAJUdPKsHIjjcjHqGDPj4CoStDA6fW9uMDtJAaWNQVcykRIJuQvdNSlK0p4rA eEKpvonbtb1RZyidI/caBn39kN9221E= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-15-6503fTaVPLqMEr27yNBRTA-1; Tue, 19 Dec 2023 11:56:43 -0500 X-MC-Unique: 6503fTaVPLqMEr27yNBRTA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9ED74185A782; Tue, 19 Dec 2023 16:56:42 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.39.195.169]) by smtp.corp.redhat.com (Postfix) with ESMTP id D48152026D66; Tue, 19 Dec 2023 16:56:39 +0000 (UTC) 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 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 Cc: dhowells@redhat.com, Steve French , Matthew Wilcox , Marc Dionne , Paulo Alcantara , Shyam Prasad N , Tom Talpey , Dominique Martinet , Eric Van Hensbergen , Ilya Dryomov , Christian Brauner , 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 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> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.4 X-Rspamd-Queue-Id: A3DD8180003 X-Rspam-User: X-Stat-Signature: fsj61tauqtnmusk5rjo7nqogyf5j1k8n X-Rspamd-Server: rspam03 X-HE-Tag: 1703005009-436302 X-HE-Meta: U2FsdGVkX19BqcnBunt2NrehR+gGeFrkgcAcJ1D2wX32kvs8b/LkAwk2yfy8gD/yExaZVe+5LW6nHMksPOQa5eEz0rPqaSHxeUtmVsSKbHj0GE7XFYDhe877ytp4k7WjcuSGZhAChtovZETYRBXBb5Crx2uj/Hvtynsuflt26lYTDhPNfg1GqUbQTqeKQEmofsiUtx+0aGRZXT9QzSaXhQKCR+KH87uPrjM1PfW/gQa3DxDQN5YsMpsOAljVTRCj8IDAMrvS3A7hIA3/79v4wXaDrVQBwl0WEpjc2nCo6f1BlPLu9KCuLuwGLXVYY0b+ui2yoj6F/+EnGQBKv/MArKyNdktvfsDCcGyeAX8oLuyU+WPCe/SlIMrd3f1DvBcLeuBzGDjgI81XIEXoFt30JmPDqtWkifBTJugISlkRKAmVfOdHko/HJubGNzHeDDDYXKCpcv9V+PMms84BeMg9XWrEEO8404kIOM73B+WrsslkxLkBp25FUVzTEgow8x34XtMnGq3dEQ3ok6qNQ6QtpcFx5nVpU7KapurLnCiGgJDob5TT7xOoa43yNDC1bcvOcvhvR9x6Q0xZmzfzxFal7bp2+j6HGVIr8F02k6hm5kv4mERF1SrcbuvFCf0ApG/Q6Y+Z9vgOg2sZWkQzpOEnzLXrK8YfIGvDijGAHEOVxj5xJgopsD5zXsSz0HSp3/c6dqgM8UyfuQzfT5cQJtTMiKeT/3gn8vl7f98pfVw8NCbS11LvoE9OSKBj7Hawdr2N3GnnILSm9QQjQJAb7vq5Zk4oSeRBnA//H8drMQWMrBNxCGkVXktOe7BjE4E7IgZyytNyiE9WQBtDzEt0D9eQ2ESsQ9mCzj/Xwcct2bFORTnEMC1oLWCU1km7V8An9d9ksVSdqBUtkcCUebln26MRhZjMeeFrVk6hqoxMawI4wxi7X7oJ6wtZY5HmiZ/FDJL6lITNsfN/qdOxMcfACT2 M9WYukki VMEIL6ZUWstN9JpHvUwZgs1InCVEakEACAQPZpwzph4x7E3V3l4ZCf4Pj25viC7iIKFAZx+d6yYHoJa8NbYlcXEbDMs3+7JGXvi5rR0SeMAQntsR9F1uP4aPrU0L9P/7/uk6djTWTw8EZNtMl55Zbyw5rzKT7n3rLpSrF2kxd5mu76//jvRyr9S8l8lDUe6IqXDUPKkXow8f/jZG0kf1Xk6NN8A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Jeff Layton 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