From: Dave Chinner <david@fromorbit.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jayashree Mohan <jayashree2912@gmail.com>,
linux-btrfs <linux-btrfs@vger.kernel.org>,
fstests <fstests@vger.kernel.org>,
linux-f2fs-devel@lists.sourceforge.net,
Vijaychidambaram Velayudhan Pillai <vijay@cs.utexas.edu>
Subject: Re: Symlink not persisted even after fsync
Date: Sat, 14 Apr 2018 00:06:40 +1000 [thread overview]
Message-ID: <20180413140640.GE5572@dastard> (raw)
In-Reply-To: <CAOQ4uxhK6DQxTdipX2SP2t1960PrRt66+k3FVxQqwTBs-67cQA@mail.gmail.com>
On Fri, Apr 13, 2018 at 08:52:19AM +0300, Amir Goldstein wrote:
> On Thu, Apr 12, 2018 at 8:51 PM, Jayashree Mohan
> <jayashree2912@gmail.com> wrote:
> > Hi,
> >
> > We came across what seems to be a crash consistency bug on btrfs and
> > f2fs. When we create a symlink for a file and fsync the symlink, on
> > recovery from crash, the fsync-ed file is missing.
> >
> > You can reproduce this behaviour using this minimal workload :
> >
> > 1. symlink (foo, bar)
> > 2. open bar
> > 3. fsync bar
> > ----crash here----
> >
> > When we recover, we find that file bar is missing. This behaviour
> > seems unexpected as the fsynced file is lost on a crash. ext4 and xfs
> > correctly recovers file bar. This seems like a bug. If not, could you
> > explain why?
> >
>
> Not a bug.
Actually, for a filesystem with strictly ordered metadata recovery
semantics, it is a bug.
> From man 2 fsync:
>
> "Calling fsync() does not necessarily ensure that the entry in the
> directory containing the file has also reached disk. For that an
> explicit fsync() on a file descriptor for the directory is also needed."
We've been through this before, many times. This caveat does not
apply to strictly ordered metadata filesystems. If you fsync a file
on an ordered metadata filesystem, then all previous transactions
that are needed to reference the file are also committed.
The behaviour from ext4 and XFS is correct for strictly ordered
filesystems. This is not a "fsync requirement", nor is it a general
linux filesystem requirement. It is a requirement of the desired
filesystem crash recovery mechanisms....
BTRFS is advertised as having strictly ordered metadata
recovery semantics, so it should behave the same way as ext4 and
XFS in tests like these. If it doesn't, then there's filesystem bugs
that need fixing...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
prev parent reply other threads:[~2018-04-13 14:06 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-12 17:51 Symlink not persisted even after fsync Jayashree Mohan
2018-04-13 5:52 ` Amir Goldstein
2018-04-13 12:57 ` Vijay Chidambaram
[not found] ` <CAPaz=E+-baGSWhL3nD-8X4jn6rKdn2AVGLeqWh3EY5Nh-RodRA@mail.gmail.com>
2018-04-13 13:16 ` Amir Goldstein
2018-04-13 14:39 ` Jayashree Mohan
2018-04-14 1:20 ` Dave Chinner
2018-04-14 3:27 ` Vijay Chidambaram
2018-04-14 21:55 ` Dave Chinner
2018-04-15 1:13 ` Vijay Chidambaram
2018-04-15 1:30 ` Theodore Y. Ts'o
2018-04-15 1:40 ` Vijay Chidambaram
2018-04-15 1:17 ` Theodore Y. Ts'o
2018-04-15 1:38 ` Vijay Chidambaram
[not found] ` <CAHWVdUXAyyeTGNXrtTTc+tUbA3t9TUjJPSF=M4Cetj4+d1w3eQ@mail.gmail.com>
2018-04-15 14:13 ` Theodore Y. Ts'o
2018-04-16 0:10 ` Vijay Chidambaram
2018-04-16 5:39 ` Amir Goldstein
2018-04-16 15:17 ` Vijay Chidambaram
2018-04-16 5:52 ` Theodore Y. Ts'o
2018-04-16 15:09 ` Vijay Chidambaram
2018-04-17 0:07 ` Dave Chinner
2018-04-17 2:56 ` Vijay Chidambaram
2018-04-13 14:06 ` Dave Chinner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180413140640.GE5572@dastard \
--to=david@fromorbit.com \
--cc=amir73il@gmail.com \
--cc=fstests@vger.kernel.org \
--cc=jayashree2912@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=vijay@cs.utexas.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).