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 X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AB0C2C33CAA for ; Thu, 23 Jan 2020 07:16:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 873A12467B for ; Thu, 23 Jan 2020 07:16:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725828AbgAWHQr (ORCPT ); Thu, 23 Jan 2020 02:16:47 -0500 Received: from mail105.syd.optusnet.com.au ([211.29.132.249]:34338 "EHLO mail105.syd.optusnet.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725535AbgAWHQq (ORCPT ); Thu, 23 Jan 2020 02:16:46 -0500 Received: from dread.disaster.area (pa49-195-162-125.pa.nsw.optusnet.com.au [49.195.162.125]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id D0CEB3A2854; Thu, 23 Jan 2020 18:16:40 +1100 (AEDT) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1iuWjH-0002Dt-I3; Thu, 23 Jan 2020 18:16:39 +1100 Date: Thu, 23 Jan 2020 18:16:39 +1100 From: Dave Chinner To: Al Viro Cc: Omar Sandoval , Amir Goldstein , Trond Myklebust , "dhowells@redhat.com" , "lsf-pc@lists.linux-foundation.org" , "hch@lst.de" , "miklos@szeredi.hu" , "linux-fsdevel@vger.kernel.org" , "Darrick J. Wong" Subject: Re: [LSF/MM/BPF TOPIC] Allowing linkat() to replace the destination Message-ID: <20200123071639.GA7216@dread.disaster.area> References: <20200117202219.GB295250@vader> <20200117222212.GP8904@ZenIV.linux.org.uk> <20200117235444.GC295250@vader> <20200118004738.GQ8904@ZenIV.linux.org.uk> <20200118011734.GD295250@vader> <20200118022032.GR8904@ZenIV.linux.org.uk> <20200121230521.GA394361@vader> <20200122221003.GB394361@vader> <20200123034745.GI23230@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200123034745.GI23230@ZenIV.linux.org.uk> User-Agent: Mutt/1.10.1 (2018-07-13) X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.3 cv=X6os11be c=1 sm=1 tr=0 a=eqEhQ2W7mF93FbYHClaXRw==:117 a=eqEhQ2W7mF93FbYHClaXRw==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=Jdjhy38mL1oA:10 a=7-415B0cAAAA:8 a=agfXOARqqYv4CNyIZKwA:9 a=CjuIK1q_8ugA:10 a=biEYGPWJfzWAr4FL6Ov7:22 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Thu, Jan 23, 2020 at 03:47:45AM +0000, Al Viro wrote: > On Wed, Jan 22, 2020 at 02:10:03PM -0800, Omar Sandoval wrote: > > > > Sorry for not reading all the thread again, some API questions: > > > - We intend to allow AT_REPLACE only with O_TMPFILE src. Right? > > > > I wasn't planning on having that restriction. It's not too much effort > > for filesystems to support it for normal files, so I wouldn't want to > > place an artificial restriction on a useful primitive. > > I'm not sure; that's how we ended up with the unspeakable APIs like > rename(2), after all... Yet it is just rename(2) with the serial numbers filed off - complete with all the same data vs metadata ordering problems that rename(2) comes along with. i.e. it needs fsync to guarantee data integrity of the source file before the linkat() call is made. If we can forsee that users are going to complain that linkat(AT_REPLACE) using O_TMPFILE files is not atomic because it leaves zero length files behind after a crash just like rename() does, then we haven't really improved anything at all... And, really, I don't think anyone wants another API that requires multiple fsync calls to use correctly for crash-safe file replacement, let alone try to teach people who still cant rename a file safely how to use it.... Cheers, Dave. -- Dave Chinner david@fromorbit.com