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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D1C59C433FE for ; Thu, 21 Oct 2021 23:43:36 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 69DD361354 for ; Thu, 21 Oct 2021 23:43:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 69DD361354 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 93C7D900002; Thu, 21 Oct 2021 19:43:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8EB5B6B0072; Thu, 21 Oct 2021 19:43:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7D9BB900002; Thu, 21 Oct 2021 19:43:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0153.hostedemail.com [216.40.44.153]) by kanga.kvack.org (Postfix) with ESMTP id 6B8876B0071 for ; Thu, 21 Oct 2021 19:43:35 -0400 (EDT) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 2A33F8249980 for ; Thu, 21 Oct 2021 23:43:35 +0000 (UTC) X-FDA: 78722073990.31.6340DB3 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf16.hostedemail.com (Postfix) with ESMTP id 9B2E9F00009B for ; Thu, 21 Oct 2021 23:43:31 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id D7B706120C; Thu, 21 Oct 2021 23:43:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1634859814; bh=LE+sfzEXJlFl8jCsBBJvLQfsmo8JPatvzUNz5xSZVrk=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=TgMVshk590paFQtbeK7zsyr4l/2uZp8+iGE+Is7GOaqOs2fjIWdb1db0zUOZCD1D/ qSIki3hnjNZxvH7hMUKP6OCN5hbiVGAv2XjSk4Vu4n2Brz1rBVrshn8bHukAQnfRRv anWSmxVujkZB4+3Vgc3zvaFf1bGC7CzMWQKe6CW34pKn5QSZJPQUjgeysNPUEJswMd t7htnv6dWAlApcY9+r9kUWKJKLIl3BAtQDDX9NUsRBx84qp+9TOpGx1yTzQZkj0kpU RPr0UXaSlLtDfKfBNDv1hq7rgvpN1ibPs6YRxvIs06BNymtP6Gi5hn9pZzMvTMTSzN l5WRtdh7ClJ1A== Message-ID: Subject: Re: [PATCH 00/67] fscache: Rewrite index API and management system From: Jeff Layton To: Steve French , Omar Sandoval Cc: David Howells , linux-cachefs@redhat.com, ceph-devel , linux-afs@lists.infradead.org, Anna Schumaker , linux-nfs , Kent Overstreet , linux-mm , Matthew Wilcox , linux-fsdevel , Dave Wysochanski , Marc Dionne , Trond Myklebust , Shyam Prasad N , Eric Van Hensbergen , v9fs-developer@lists.sourceforge.net, CIFS , Latchesar Ionkov , Steve French , Al Viro , Dominique Martinet , Ilya Dryomov , Trond Myklebust , Linus Torvalds , LKML Date: Thu, 21 Oct 2021 19:43:30 -0400 In-Reply-To: References: <163456861570.2614702.14754548462706508617.stgit@warthog.procyon.org.uk> Content-Type: text/plain; charset="ISO-8859-15" User-Agent: Evolution 3.40.4 (3.40.4-2.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 9B2E9F00009B X-Stat-Signature: s4otjeza7ea4kiyx83k8x6e315pdtu9u Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=TgMVshk5; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf16.hostedemail.com: domain of jlayton@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=jlayton@kernel.org X-HE-Tag: 1634859811-343374 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: On Thu, 2021-10-21 at 18:15 -0500, Steve French wrote: > On Thu, Oct 21, 2021 at 5:21 PM Omar Sandoval wrote: > > > > On Mon, Oct 18, 2021 at 03:50:15PM +0100, David Howells wrote: > > However, with the advent of the tmpfile capacity in the VFS, an opportunity > > arises to do invalidation much more easily, without having to wait for I/O > > that's actually in progress: Cachefiles can simply cut over its file > > pointer for the backing object attached to a cookie and abandon the > > in-progress I/O, dismissing it upon completion. > > Have changes been made to O_TMPFILE? It is problematic for network filesystems > because it is not an atomic operation, and would be great if it were possible > to create a tmpfile and open it atomically (at the file system level). > > Currently it results in creating a tmpfile (which results in > opencreate then close) > immediately followed by reopening the tmpfile which is somewhat counter to > the whole idea of a tmpfile (ie that it is deleted when closed) since > the syscall results > in two opens ie open(create)/close/open/close > > In this case, O_TMPFILE is being used on the cachefiles backing store, and that usually isn't deployed on a netfs. That said, Steve does have a good point... What happens if you do end up without O_TMPFILE support on the backing store? Probably just opting to not cache in that case is fine. Does cachefiles just shut down in that situation? -- Jeff Layton