On Thu, Jan 23, 2020 at 9:16 AM Dave Chinner <david@xxxxxxxxxxxxx> 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 have too many gray hairs each one for implementing a "useful primitive" that nobody asked for and bare the consequences. Your introduction to AT_REPLACE uses O_TMPFILE. I see no other sane use of the interface. > > 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.... > Are you suggesting that AT_LINK_REPLACE should have some of the semantics I posted in this RFC for AT_ATOMIC_xxx: https://lore.kernel.org/linux-fsdevel/20190527172655.9287-1-amir73il@xxxxxxxxx/ I admit I did not follow up on performance benchmarks that you asked on that thread, but I also see the value in a simple API as opposed to the AIO_FSYNC scheme that you proposed. Thanks, Amir.
