All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: "Lukáš Czerner" <lczerner@redhat.com>
Cc: Eryu Guan <guaneryu@gmail.com>, linux-ext4@vger.kernel.org
Subject: Re: [PATCH] ext4: don't cache out of order extents
Date: Thu, 17 Oct 2013 11:58:25 -0400	[thread overview]
Message-ID: <20131017155825.GB3605@thunk.org> (raw)
In-Reply-To: <alpine.LFD.2.00.1310171704300.3212@localhost.localdomain>

On Thu, Oct 17, 2013 at 05:22:58PM +0200, Lukáš Czerner wrote:
> 
> I agree, since ext4_ext_check() should be really only used when
> reading data from disk. That said, we might actually remove the
> check from ext4_ext_precache() and ext4_ext_remove_space() because
> it seems to be that the check has already been done in ext4_iget()
> and it should be enough to check it once when reading from disk,
> right ?

Yes, since we do call ext4_ext_check() in ext4_iget() to verify the
root node of the extent tree located in ei->i_blocks[], it's strictly
speaking not necessary.  OTOH, there are at most four entries in
i_blocks[] that need to be verified, and it's a bit easier for the
contents of i_blocks[] to get corrupted by buggy code, so it's a
toss-up whether it's really worth it to remove it from those two
places, which aren't really hotspots.  It could be argued that are
plenty of other places that where we're not validating the root extent
tree node, so we might as well remove it from those two functions,
though.

> > Eryu's patch, or something like it, will still be needed so that in
> > the case of errors=countinue, we don't end up calling BUG_ON().
> 
> Hmm shouldn't we avoid that data in the case that it's corrupted
> rather than using it ? It seems like this is what the code would do
> anyway even with errors=continue when __ext4_ext_check() returns
> error.

Hmm, maybe we should set a flag indicating that the inode is bad, and
then cause attempts to read or write the contents of that inode should
return EIO.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2013-10-17 15:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-17  9:27 [PATCH] ext4: don't cache out of order extents Eryu Guan
2013-10-17 13:44 ` Lukáš Czerner
2013-10-17 14:40   ` Theodore Ts'o
2013-10-17 15:22     ` Lukáš Czerner
2013-10-17 15:58       ` Theodore Ts'o [this message]
2013-10-17 15:06   ` Eryu Guan
2013-10-20 13:27 ` [PATCH v2] ext4: check for overlapping extents in ext4_valid_extent_entries() Eryu Guan
2013-10-21 11:59   ` Eryu Guan
2013-10-21 12:47     ` Eryu Guan
2013-10-21 16:06   ` Lukáš Czerner
2013-10-22 18:40     ` Eryu Guan
2013-12-04  2:36       ` [PATCH v3] " Theodore 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=20131017155825.GB3605@thunk.org \
    --to=tytso@mit.edu \
    --cc=guaneryu@gmail.com \
    --cc=lczerner@redhat.com \
    --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.