On Fri, May 31, 2019 at 7:41 PM Theodore Ts'o <tytso@xxxxxxx> wrote:
>
> On Fri, May 31, 2019 at 06:21:45PM +0300, Amir Goldstein wrote:
> > What do you think of:
> >
> > "AT_ATOMIC_DATA (since Linux 5.x)
> > A filesystem which accepts this flag will guarantee that if the linked file
> > name exists after a system crash, then all of the data written to the file
> > and all of the file's metadata at the time of the linkat(2) call will be
> > visible.
>
> ".... will be visible after the the file system is remounted". (Never
> hurts to be explicit.)
>
> > The way to achieve this guarantee on old kernels is to call fsync (2)
> > before linking the file, but doing so will also results in flushing of
> > volatile disk caches.
> >
> > A filesystem which accepts this flag does NOT
> > guarantee that any of the file hardlinks will exist after a system crash,
> > nor that the last observed value of st_nlink (see stat (2)) will persist."
> >
>
> This is I think more precise:
>
> This guarantee can be achieved by calling fsync(2) before linking
> the file, but there may be more performant ways to provide these
> semantics. In particular, note that the use of the AT_ATOMIC_DATA
> flag does *not* guarantee that the new link created by linkat(2)
> will be persisted after a crash.
OK. Just to be clear, mentioning hardlinks and st_link is not needed
in your opinion?
>
> We should also document that a file system which does not implement
> this flag MUST return EINVAL if it is passed this flag to linkat(2).
>
OK. I think this part can be documented as possible reason for EINVAL
As in renameat(2) man page:
EINVAL The filesystem does not support one of the flags in flags.
Thanks,
Amir.
