linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sami Liedes <sami.liedes@iki.fi>
To: Ted Ts'o <tytso@mit.edu>
Cc: Andreas Dilger <adilger@dilger.ca>, linux-ext4@vger.kernel.org
Subject: Re: [PATCH 4/5] libext2fs: Implement ext2fs_find_first_zero_generic_bmap().
Date: Mon, 26 Mar 2012 16:53:56 +0300	[thread overview]
Message-ID: <20120326135355.GB2180@cc.hut.fi> (raw)
In-Reply-To: <20120323223331.GA8554@thunk.org>

On Fri, Mar 23, 2012 at 06:33:31PM -0400, Ted Ts'o wrote:
> It would then be very easy to build iterators on *top* of
> find_first_zero() and find_first_set(), and in fact this could be used
> to replace some of the places where we are using a sorted list (i.e.,
> the badblocks list).  So that sounds like a good idea, and I can
> definitely think of some places where we could use that code today.
> 
> So I plan to pull in your patch series and then we can further enhance
> this with iterator support afterwards.  Sami, if you'd be interested
> in implementing iterators, that would be great!

Just to be on the same page, what is the motivation for iterators? Is
it performance, making the code cleaner or facilitating further
functionality?

If it's driven by performance concerns, it would be good to first have
a case where they cause performance problems. Otherwise it would be
good to first figure out a program in the e2fsprogs suite that
exercises (or could exercise) the code in question, just for testing.

My work on inode allocation was actually entirely driven by a friend's
observation that resize2fs took 16 CPU hours to shrink a filesystem.
Profile-guided optimization is something I generally do a lot, but I'm
not averse to doing other kinds of useful coding tasks for useful open
source projects.

	Sami

  reply	other threads:[~2012-03-26 13:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-10 21:33 [PATCH 0/5] Make filesystem shrinking faster and less CPU-intensive Sami Liedes
2012-03-10 21:34 ` [PATCH 1/5] libext2fs: Move a modulo operation out of a hot loop Sami Liedes
2012-03-11  9:50   ` Andreas Dilger
2012-03-10 21:35 ` [PATCH 2/5] resize2fs: Use EXT2_FLAG_64BITS Sami Liedes
2012-03-10 21:36 ` [PATCH 3/5] libext2fs: Document EXT2_FLAG_64BITS in ext2fs_open2() Sami Liedes
2012-03-10 21:37 ` [PATCH 4/5] libext2fs: Implement ext2fs_find_first_zero_generic_bmap() Sami Liedes
2012-03-11  9:51   ` Andreas Dilger
2012-03-12 19:15     ` Sami Liedes
2012-03-12 23:09       ` Andreas Dilger
2012-03-23 22:33       ` Ted Ts'o
2012-03-26 13:53         ` Sami Liedes [this message]
2012-03-26 15:34           ` Ted Ts'o
2012-03-26  2:39   ` Ted Ts'o
2012-03-10 21:38 ` [PATCH 5/5] libext2fs: Implement fast find_first_zero() for bitarray bitmaps Sami Liedes
2012-03-26  2:34   ` Ted Ts'o
2012-03-26 13:22     ` Sami Liedes
2012-03-26 15:26       ` Ted 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=20120326135355.GB2180@cc.hut.fi \
    --to=sami.liedes@iki.fi \
    --cc=adilger@dilger.ca \
    --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 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).