linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@redhat.com>
To: 焦晓冬 <milestonejxd@gmail.com>, linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Rogier Wolff <R.E.Wolff@BitWizard.nl>
Subject: Re: POSIX violation by writeback error
Date: Tue, 04 Sep 2018 06:56:53 -0400	[thread overview]
Message-ID: <486f6105fd4076c1af67dae7fdfe6826019f7ff4.camel@redhat.com> (raw)
In-Reply-To: <CAJDTihx2yaR-_-9Ks1PoFcrKNZgUOoLdN-wRTTMV76Jg_dCLrw@mail.gmail.com>

On Tue, 2018-09-04 at 13:42 +0800, 焦晓冬 wrote:
> Hi,
> 
> After reading several writeback error handling articles from LWN, I
> begin to be upset about writeback error handling.
> 
> Jlayton's patch is simple but wonderful idea towards correct error
> reporting. It seems one crucial thing is still here to be fixed. Does
> anyone have some idea?
> 
> The crucial thing may be that a read() after a successful open()-
> write()-close() may return old data. 
> That may happen where an async writeback error occurs after close()
> and the inode/mapping get evicted before read().
>
> That violate POSIX as POSIX requires that a read() that can be proved
> to occur after a write() has returned will return the new data.

That can happen even before a close(), and it varies by filesystem. Most
filesystems just pretend the page is clean after writeback failure. It's
quite possible to do:

write()
kernel attempts to write back page and fails
page is marked clean and evicted from the cache
read()

Now your write is gone and there were no calls between the write and
read.

The question we still need to answer is this:

When we attempt to write back some data from the cache and that fails,
what should happen to the dirty pages?

Unfortunately, there are no good answers given the write/fsync/read
model for I/O. I tend to think that in the long run we may need new
interfaces to handle this better.
-- 
Jeff Layton <jlayton@redhat.com>

       reply	other threads:[~2018-09-04 15:21 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAJDTihx2yaR-_-9Ks1PoFcrKNZgUOoLdN-wRTTMV76Jg_dCLrw@mail.gmail.com>
2018-09-04 10:56 ` Jeff Layton [this message]
2018-09-24 23:30   ` POSIX violation by writeback error Alan Cox
2018-09-25 11:15     ` Jeff Layton
2018-09-25 15:46       ` Theodore Y. Ts'o
2018-09-25 16:17         ` Rogier Wolff
2018-09-25 16:39         ` Alan Cox
2018-09-25 16:41         ` Jeff Layton
2018-09-25 22:30           ` Theodore Y. Ts'o
2018-09-26 18:10             ` Alan Cox
2018-09-26 21:49               ` Theodore Y. Ts'o
2018-09-27 22:48                 ` Alan Cox
2018-09-27  7:18               ` Rogier Wolff
2018-09-27 12:43             ` Jeff Layton
2018-09-27 14:27               ` Theodore Y. Ts'o
2018-09-25 17:35         ` Adam Borowski
2018-09-25 22:46           ` Theodore Y. Ts'o
2018-09-04  6:32 焦晓冬
2018-09-04  7:53 ` Rogier Wolff
2018-09-04  8:58   ` 焦晓冬
2018-09-04  9:29     ` Rogier Wolff
2018-09-04 10:45       ` 焦晓冬
2018-09-04 11:09     ` Jeff Layton
2018-09-04 14:56       ` 焦晓冬
2018-09-04 15:44         ` Jeff Layton
2018-09-04 16:12           ` J. Bruce Fields
2018-09-04 16:23             ` Rogier Wolff
2018-09-04 18:54               ` J. Bruce Fields
2018-09-04 20:18                 ` Jeff Layton
2018-09-04 20:35                   ` Vito Caputo
2018-09-04 21:02                     ` Matthew Wilcox
2018-09-05  0:51                     ` Dave Chinner
2018-09-05  8:24                   ` 焦晓冬
2018-09-05 10:55                     ` Jeff Layton
2018-09-05 12:07                       ` Rogier Wolff
2018-09-06  2:57                         ` Dave Chinner
2018-09-06  9:17                           ` Rogier Wolff
2018-09-24 23:09                             ` Alan Cox
2018-09-05 13:53                       ` J. Bruce Fields
2018-09-05  7:08           ` Rogier Wolff
2018-09-05  7:39             ` Martin Steigerwald
2018-09-05  8:04               ` Rogier Wolff
2018-09-05  8:37                 ` 焦晓冬
2018-09-05 12:07                   ` Austin S. Hemmelgarn
2018-09-05 12:46                     ` Rogier Wolff
2018-09-05  9:32                 ` Martin Steigerwald
2018-09-05  7:37           ` Martin Steigerwald
2018-09-05 11:42             ` Jeff Layton
2018-09-05  8:09           ` 焦晓冬
2018-09-05 13:08             ` Theodore Y. Ts'o
2018-09-24 23:21               ` Alan Cox
2018-09-06  7:28             ` 焦晓冬

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=486f6105fd4076c1af67dae7fdfe6826019f7ff4.camel@redhat.com \
    --to=jlayton@redhat.com \
    --cc=R.E.Wolff@BitWizard.nl \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=milestonejxd@gmail.com \
    /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).