linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ted Ts'o <tytso@mit.edu>, Jan Kara <jack@suse.cz>,
	linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	LKML <linux-kernel@vger.kernel.org>,
	Edward Shishkin <edward@redhat.com>
Subject: Re: [RFC PATCH 0/3] Stop clearing uptodate flag on write IO error
Date: Tue, 24 Jan 2012 17:12:11 +1100	[thread overview]
Message-ID: <20120124061211.GK15102@dastard> (raw)
In-Reply-To: <CA+55aFxggjW6FKhf7KSCRMD-4YF9ymsxDQ+EMtUTThX16r-8tw@mail.gmail.com>

On Mon, Jan 23, 2012 at 03:49:39PM -0800, Linus Torvalds wrote:
> On Mon, Jan 23, 2012 at 1:47 PM, Ted Ts'o <tytso@mit.edu> wrote:
> >
> > So how does XFS decide whether a write should fail and shutdown the
> > file system, or just "try forever"?
> 
> Why would it bother? XFS tends to be a filesystem that you'd only use
> for core files in environments where you have a system manager that
> knows what he is doing.

Oh, man, what a troll.

Even my *TV* uses XFS. First google reference:

http://settorezero.blogspot.com/2010/10/xfs-filesystem-and-samsung-ledtvs.html

You won't find a more hostile "pull-the-drive-without-unmounting"
environment than a TV. XFS handles this sort of stuff just fine and
it has for a long time.

> So there, maybe "try forever" is the right
> thing to do.

You still haven't grasped that there are many different
classes of IO errors and that some require different handling to
others. :/

> Things are a bit different with some random unreliable USB stick FAT32
> filesystem that just died on you, with a normal user that just removes
> the thing or doesn't even notice that the stick is now dead. There the
> "try forever" is totally the wrong thing to do.

I'm not saying that "try forever" is how all errors should be
handled. You are completely focussed on that as the only possible
error handling technique that can be used. Stop being stupid!

I'm saying that the dirty, uptodate, errored buffer should
be handled back to the filesystem so that it can decide what to do
with it.  For filesystems that can differentiate the types of
errors, let them choose how to handle the problem. Those that are
unable to handle the error can do the invalidation themselves. One
size does not fit all...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2012-01-24  6:12 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-05 14:40 [RFC PATCH 0/3] Stop clearing uptodate flag on write IO error Jan Kara
2012-01-05 14:40 ` [PATCH 1/3] fs: Convert checks for write IO errors from !buffer_uptodate to buffer_write_io_error Jan Kara
2012-01-05 14:40 ` [PATCH 2/3] fs: Do not clear uptodate flag on write IO error Jan Kara
2012-01-05 14:40 ` [PATCH 3/3] ext2: Replace tests of write IO errors using buffer_uptodate Jan Kara
2012-01-05 22:16 ` [RFC PATCH 0/3] Stop clearing uptodate flag on write IO error Andrew Morton
2012-01-15  2:19 ` Linus Torvalds
2012-01-16 16:01   ` Jan Kara
2012-01-16 18:55     ` Linus Torvalds
2012-01-16 19:06       ` Linus Torvalds
2012-01-17  0:36       ` Dave Chinner
2012-01-17  0:59         ` Linus Torvalds
2012-01-17 10:46           ` Boaz Harrosh
2012-01-23  3:04           ` Dave Chinner
2012-01-23 21:47             ` Ted Ts'o
2012-01-23 23:49               ` Linus Torvalds
2012-01-24  6:12                 ` Dave Chinner [this message]
2012-01-24  7:10                   ` Linus Torvalds
2012-01-24 12:13                     ` Jan Kara
2012-01-24  0:36               ` Dave Chinner
2012-01-26 12:17                 ` Ric Wheeler
2012-01-26 20:51                   ` Jan Kara
2012-01-26 20:58                     ` Ric Wheeler

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=20120124061211.GK15102@dastard \
    --to=david@fromorbit.com \
    --cc=akpm@linux-foundation.org \
    --cc=edward@redhat.com \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    /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).