Re: [LSF/MM/BPF TOPIC] Allowing linkat() to replace the destination

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jan 23, 2020 at 06:16:39PM +1100, Dave Chinner wrote:
> 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....

AT_REPLACE would have a leg up in that we can at least mention the (lack
of) integrity guarantees in the man page. It's no suprise that no one
gets rename right when the documentation make no mention of
integrity/durability/crash safety.

Sure, if everyone wants AT_REPLACE to guarantee integrity, we can do
that. But I'm going to start with the simplest proposal that makes no
such guarantees.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux