Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <486f6105fd4076c1af67dae7fdfe6826019f7ff4.camel@redhat.com>
Subject: Re: POSIX violation by writeback error
From:   Jeff Layton <jlayton@redhat.com>
To:     =?UTF-8?Q?=E7=84=A6=E6=99=93=E5=86=AC?= <milestonejxd@gmail.com>,
        linux-fsdevel@vger.kernel.org
Cc:     linux-kernel@vger.kernel.org, Rogier Wolff <R.E.Wolff@BitWizard.nl>
Date:   Tue, 04 Sep 2018 06:56:53 -0400
In-Reply-To: <CAJDTihx2yaR-_-9Ks1PoFcrKNZgUOoLdN-wRTTMV76Jg_dCLrw@mail.gmail.com>
References: <CAJDTihx2yaR-_-9Ks1PoFcrKNZgUOoLdN-wRTTMV76Jg_dCLrw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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>