From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f195.google.com ([209.85.192.195]:36938 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751704AbeEDSaP (ORCPT ); Fri, 4 May 2018 14:30:15 -0400 Received: by mail-pf0-f195.google.com with SMTP id e9so14077773pfi.4 for ; Fri, 04 May 2018 11:30:15 -0700 (PDT) Date: Fri, 4 May 2018 11:30:13 -0700 From: Omar Sandoval To: Al Viro , linux-fsdevel@vger.kernel.org Cc: Linus Torvalds , linux-api@vger.kernel.org, kernel-team@fb.com, Xi Wang Subject: Re: [RFC PATCH v3 0/2] fs: add AT_REPLACE flag for linkat() Message-ID: <20180504183013.GD26037@vader> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Apr 23, 2018 at 11:19:40PM -0700, Omar Sandoval wrote: > From: Omar Sandoval > > Hi, Al, > > This is a respin of my linkat() AT_REPLACE series, previously posted > here: > > https://patchwork.kernel.org/patch/9636735/ > https://patchwork.kernel.org/patch/9636733/ > > There are no changes since v2, only a rebase onto v4.17-rc2 and some > minor additions to the commit messages. > > The goal is to allow for updating a file atomically in-place with an > O_TMPFILE like so: > > - open temporary file with O_TMPFILE > - write temporary file contents > - fsync temporary file > - atomically replace permanent location with the temporary file > - fsync parent directory > > Patch 1 implements the VFS support for this flag. The implementation > resembles sys_renameat2(), and I took care to preserve all of the > original error cases and make the new error cases consistent with > rename. > > Previously, we discussed extending renameat2() instead of linkat() for > this, but this makes a mess of rename and also forces us to special-case > the parent directory for O_TMPFILEs in implementations of > i_op->rename(), so I still think linkat() is a better fit. > > Patch 2 adds support for AT_REPLACE to Btrfs. That's the codebase I'm > most familiar with so that's where I started, but it should be > straightforward to implement for other filesystems. v1 of this series > had some incorrect dentry fiddling, so now I just unhash the replaced > dentry for simplicity. > > Please take a look. > > Thanks! Ping, Al, can you take a look?