All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Lukáš Czerner" <lczerner@redhat.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: "Lukáš Czerner" <lczerner@redhat.com>, linux-ext4@vger.kernel.org
Subject: Re: [PATCH 1/2] ext4: call WARN_ON after the debug message
Date: Fri, 25 Jan 2013 16:14:30 +0100 (CET)	[thread overview]
Message-ID: <alpine.LFD.2.00.1301251613260.20753@localhost> (raw)
In-Reply-To: <20130125150948.GK28908@thunk.org>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1553 bytes --]

On Fri, 25 Jan 2013, Theodore Ts'o wrote:

> Date: Fri, 25 Jan 2013 10:09:48 -0500
> From: Theodore Ts'o <tytso@mit.edu>
> To: Lukáš Czerner <lczerner@redhat.com>
> Cc: linux-ext4@vger.kernel.org
> Subject: Re: [PATCH 1/2] ext4: call WARN_ON after the debug message
> 
> On Fri, Jan 25, 2013 at 10:22:44AM +0100, Lukáš Czerner wrote:
> > 
> > we can get the EIO error from ext4_map_blocks not only in the case
> > of hardware error. The extent tree might not be in consistent state,
> > or we could even ask for blocks outside the file system itself (I
> > believe I've seen this before) and I think that in those cases it
> > might be worth to all WARN_ON.
> 
> Sure, but in those cases, the file system is corrupt, and we should
> have thrown an ext4_error() in ext4_map_blocks().  The point is that a
> WARN_ON is only useful if there is a potential programming bug.  If we
> know for sure that it's caused by a file system corruption, then we
> don't want to throw a WARN_ON.
> 
> Even if there is a kerneloops.org replacement --- in fact, especially
> if there is kerneloops.org replacement --- we only want to throw
> WARN_ON's in cases where it's just a pedestrian file system
> corruption.  Otherwise we'll end up wasting a lot of time chasing down
> something which was caused by a hardware error, and needing to calm
> down users (and breathless, spectacularizing, irresponsible journalism
> from web sites such as Phoronix).
> 
> 					- Ted

Fair enough, I'll remove the WARN_ON and use ext4_warning() instead
of ext4_msg.

Thanks!
-Lukas

  reply	other threads:[~2013-01-25 15:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-24 16:30 [PATCH 1/2] ext4: call WARN_ON after the debug message Lukas Czerner
2013-01-24 16:30 ` [PATCH 2/2] ext4: remove unused variable flags Lukas Czerner
2013-01-24 16:46   ` gnehzuil.liu
2013-01-24 16:44 ` [PATCH 1/2] ext4: call WARN_ON after the debug message gnehzuil.liu
2013-01-24 19:54 ` Theodore Ts'o
2013-01-25  9:22   ` Lukáš Czerner
2013-01-25 15:09     ` Theodore Ts'o
2013-01-25 15:14       ` Lukáš Czerner [this message]
2013-01-26  1:00       ` Dave Chinner
2013-01-28  7:10         ` Lukáš Czerner

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=alpine.LFD.2.00.1301251613260.20753@localhost \
    --to=lczerner@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.