All of lore.kernel.org
 help / color / mirror / Atom feed
From: tytso@mit.edu
To: Frank Mayhar <fmayhar@google.com>
Cc: Curt Wohlgemuth <curtw@google.com>,
	ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: Bug in extent zeroout: blocks not marked as new
Date: Mon, 23 Nov 2009 18:20:04 -0500	[thread overview]
Message-ID: <20091123232004.GG2183@thunk.org> (raw)
In-Reply-To: <1259011043.25937.29.camel@bobble.smo.corp.google.com>

On Mon, Nov 23, 2009 at 01:17:23PM -0800, Frank Mayhar wrote:
> I think the missing bit of information here is that this is happening on
> converted ext2 partitions.  Older non-extent-based files are being
> gradually removed while new extent-based files are being created.  Last
> week, Curt found that in certain cases newly-reallocated metadata blocks
> are being hit; these metadata blocks just happen to be newly-emptied
> indirect blocks (freed by a recent delete), which just happen to have
> been filled with zeroes as they were emptied.  As I recall, Curt found
> that these were pretty clearly the source of the blocks being written in
> this case.

Ah, right, the zero'ed blocks are coming from indirect blocks of files
that were being unlinked/truncated.  Got it.

> Finally, we have a question about the zero-out path:  Is there any
> known, concrete improvement given by doing the zero-out as opposed to
> just continuing to split the extents?  At the moment, by the way, there
> is one definite problem: Since it doesn't try to do a merge left (which
> it should) it invariably leaves a 14-block extent fragment, thus
> increasing fragmentation of the file.  It's not a huge problem (since
> the extents are in fact contiguous) but it's there.

Reducing extents "fragmentation" (the number of extents in the extent
tree, even though the block allocation remains contiguous) was one
reason.  Another was reducing the number of blocks that need to be
journaled, and in the case where adding an extent might cause a split;
this can be problematic if we don't have any more free blocks
available, and at the moment, not only do we not have any tree merging
code, we don't have code to decrease the tree depth once an extent
split forces us to increase the height of the tree.

Also, a contiguous write should be faster than needing to seek to the
extent tree leaf block as well as to the journal, although we haven't
measured whether the breakpoints for when we split the extent and when
we do the zero-out are ideal.  That's something we should do.

      	  	       	       	      		- Ted

      parent reply	other threads:[~2009-11-23 23:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-23 18:17 Bug in extent zeroout: blocks not marked as new Curt Wohlgemuth
2009-11-23 19:50 ` tytso
2009-11-23 21:17   ` Frank Mayhar
2009-11-23 21:45     ` Andreas Dilger
2009-11-23 23:20     ` tytso [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=20091123232004.GG2183@thunk.org \
    --to=tytso@mit.edu \
    --cc=curtw@google.com \
    --cc=fmayhar@google.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.