[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOQ4uxgj94WR82iHE4PDGSD0UDxG5sCtr+Sv+t1sOHHmnXFYzQ@mail.gmail.com>
Date: Fri, 31 May 2019 18:21:45 +0300
From: Amir Goldstein <amir73il@...il.com>
To: "Theodore Ts'o" <tytso@....edu>
Cc: Jan Kara <jack@...e.cz>,
"Darrick J . Wong" <darrick.wong@...cle.com>,
Dave Chinner <david@...morbit.com>, Chris Mason <clm@...com>,
Al Viro <viro@...iv.linux.org.uk>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
linux-xfs <linux-xfs@...r.kernel.org>,
Ext4 <linux-ext4@...r.kernel.org>,
Linux Btrfs <linux-btrfs@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>
Subject: Re: [RFC][PATCH] link.2: AT_ATOMIC_DATA and AT_ATOMIC_METADATA
> >
> > So instead of saying "A filesystem that accepts this flag will
> > guaranty, that old inode data will not be exposed in the new linked
> > name." It's much clearer to state this in the affirmative:
> >
> > A filesystem which accepts this flag will guarantee that if
> > the new pathname exists after a crash, all of the data written
> > to the file at the time of the linkat(2) call will be visible.
> >
>
> Sounds good to me. I will take a swing at another patch.
>
So I am down to single flag documented with 3 tweets ;-)
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.
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."
Thanks,
Amir.
Powered by blists - more mailing lists