All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Jan Kara <jack@suse.cz>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH -v2 1/2] ext4: save the error code which triggered an ext4_error() in the superblock
Date: Fri, 13 Dec 2019 13:50:02 -0500	[thread overview]
Message-ID: <20191213185002.GC273569@mit.edu> (raw)
In-Reply-To: <20191213112910.GD15474@quack2.suse.cz>

On Fri, Dec 13, 2019 at 12:29:10PM +0100, Jan Kara wrote:
> On Tue 03-12-19 22:23:34, Theodore Ts'o wrote:
> > This allows the cause of an ext4_error() report to be categorized
> > based on whether it was triggered due to an I/O error, or an memory
> > allocation error, or other possible causes.  Most errors are caused by
> > a detected file system inconsistency, so the default code stored in
> > the superblock will be EXT4_ERR_EFSCORRUPTED.
> > 
> > Previous-Version-Link: https://lore.kernel.org/r/20191121183036.29385-1-tytso@mit.edu
> > Signed-off-by: Theodore Ts'o <tytso@mit.edu>
> 
> Somewhat late to the party but: Seeing that you basically call
> ext4_set_errno() before every ext4_error() call (or its variants), won't it
> be more concise and less error proned to add errno as an argument to
> ext4_error() and handle setting from there? Or are there times where you
> don't want error set?

There are about 100 calls to ext4_error or its variants in fs/ext4.
This patch inserts ext4_set_errno() before roughly 20 of them.  Most
of the time, we call ext4_error() because we've found a file system
inconsistency.  So the default if ext4_set_errno() hasn't been called
is EXT4_ERR_EFSCORRUPTED.

I thought about adding errno as an argument to ext4_error(), but it
would have substantially increased the size of the patch.

Cheers,

						- Ted

      reply	other threads:[~2019-12-13 20:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-04  3:23 [PATCH -v2 1/2] ext4: save the error code which triggered an ext4_error() in the superblock Theodore Ts'o
2019-12-04  3:23 ` [PATCH -v2 2/2] ext4: simulate various I/O and checksum errors when reading metadata Theodore Ts'o
2019-12-05 19:05   ` Andreas Dilger
2019-12-09  1:23     ` [PATCH -v3] " Theodore Ts'o
2019-12-09  4:14       ` Andreas Dilger
2019-12-13 18:45         ` Theodore Y. Ts'o
2019-12-13 11:29 ` [PATCH -v2 1/2] ext4: save the error code which triggered an ext4_error() in the superblock Jan Kara
2019-12-13 18:50   ` Theodore Y. Ts'o [this message]

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=20191213185002.GC273569@mit.edu \
    --to=tytso@mit.edu \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    /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.