linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
To: Rogier Wolff <R.E.Wolff@BitWizard.nl>
Cc: "Dave Chinner" <david@fromorbit.com>,
	"Jeff Layton" <jlayton@redhat.com>, 焦晓冬 <milestonejxd@gmail.com>,
	bfields@fieldses.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: POSIX violation by writeback error
Date: Tue, 25 Sep 2018 00:09:30 +0100	[thread overview]
Message-ID: <20180925000930.3d4a93fd@alans-desktop> (raw)
In-Reply-To: <20180906091718.GL24519@BitWizard.nl>

On Thu, 6 Sep 2018 11:17:18 +0200
Rogier Wolff <R.E.Wolff@BitWizard.nl> wrote:

> On Thu, Sep 06, 2018 at 12:57:09PM +1000, Dave Chinner wrote:
> > On Wed, Sep 05, 2018 at 02:07:46PM +0200, Rogier Wolff wrote:  
> 
> > > And this has worked for years because
> > > the kernel caches stuff from inodes and data-blocks. If you suddenly
> > > write stuff to harddisk at 10ms for each seek between inode area and
> > > data-area..  
> > 
> > You're assuming an awful lot about filesystem implementation here.
> > Neither ext4, btrfs or XFS issue physical IO like this when flushing
> > data.  
> 
> My thinking is: When fsync (implicit or explicit)  needs to know 
> the result of the underlying IO, it needs to wait for it to have
> happened.

Worse than that. In many cases it needs to wait for the I/O command to
have been accepted and confirmed by the drive, then tell the disk to do a
commit to physical media, then see if that blows up. A confirmation the
disk got the data is not a confirmation that it's stable. Your disk can
also reply from its internal cache with data that will fail to hit the
media a few seconds later.

Given a cache flush on an ATA disk can take 7 seconds I'm not fond of it
8) Fortunately spinning rust is on the way out.

It's even uglier in truth. Spinning rust rewrites sectors under you
by magic without your knowledge and in freaky cases you can have data
turn error that you've not even touched this month. Flash has some
similar behaviour although it can at least use a supercap to do real work.

You can also issue things like a single 16K write and have only the last
8K succeed and the drive report an error, which freaks out some supposedly
robust techniques.

Alan

  reply	other threads:[~2018-09-25  5:14 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-04  6:32 POSIX violation by writeback error 焦晓冬
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 [this message]
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             ` 焦晓冬
     [not found] <CAJDTihx2yaR-_-9Ks1PoFcrKNZgUOoLdN-wRTTMV76Jg_dCLrw@mail.gmail.com>
2018-09-04 10:56 ` Jeff Layton
2018-09-24 23:30   ` 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

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=20180925000930.3d4a93fd@alans-desktop \
    --to=gnomes@lxorguk.ukuu.org.uk \
    --cc=R.E.Wolff@BitWizard.nl \
    --cc=bfields@fieldses.org \
    --cc=david@fromorbit.com \
    --cc=jlayton@redhat.com \
    --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).