Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
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: <20200117162201.GA282012@vader>
References: <20200117162201.GA282012@vader> <2397bb4a-2ca2-4b44-8c79-64efba9aa04d@www.fastmail.com> <20200114170250.GA8904@ZenIV.linux.org.uk> <3326.1579019665@warthog.procyon.org.uk> <9351.1579025170@warthog.procyon.org.uk> <359591.1579261375@warthog.procyon.org.uk>
To:     Omar Sandoval <osandov@osandov.com>
Cc:     dhowells@redhat.com, Colin Walters <walters@verbum.org>,
        Al Viro <viro@zeniv.linux.org.uk>,
        linux-fsdevel@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
        Theodore Ts'o <tytso@mit.edu>, adilger.kernel@dilger.ca,
        "Darrick J. Wong" <darrick.wong@oracle.com>,
        Chris Mason <clm@fb.com>, josef@toxicpanda.com,
        dsterba@suse.com, linux-ext4 <linux-ext4@vger.kernel.org>,
        xfs <linux-xfs@vger.kernel.org>, linux-btrfs@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: Making linkat() able to overwrite the target
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <469670.1579279148.1@warthog.procyon.org.uk>
Content-Transfer-Encoding: quoted-printable
Date:   Fri, 17 Jan 2020 16:39:08 +0000
Message-ID: <469671.1579279148@warthog.procyon.org.uk>
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk

Omar Sandoval <osandov@osandov.com> wrote:

> Yes I still have those patches lying around and I'd be happy to dust
> them off and resend them.

That would be great if you could.  I could use them here:

	https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log=
/?h=3Dfscache-iter

I'm performing invalidation by creating a vfs_tmpfile() and then replacing=
 the
on-disk file whilst letting ops resume on the temporary file.  Replacing t=
he
on-disk file currently, however, involves unlinking the old one before I c=
an
link in a new one - which leaves a window in which nothing is there.  I co=
uld
use one or more side dirs in which to create new files and rename them ove=
r,
but that has potential lock bottleneck issues - and is particularly fun if=
 an
entire volume is invalidated (e.g. AFS vos release).

David