linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Dmitry Monakhov <dmonakhov@openvz.org>
Cc: "Andreas Dilger" <adilger@dilger.ca>,
	"Lukáš Czerner" <lczerner@redhat.com>,
	linux-ext4@vger.kernel.org
Subject: Re: [RFC PATCH 1/1] ext4: Try to better reuse recently freed space
Date: Tue, 1 Apr 2014 10:47:08 -0400	[thread overview]
Message-ID: <20140401144708.GT4911@thunk.org> (raw)
In-Reply-To: <87ioqtuvd6.fsf@openvz.org>

On Tue, Apr 01, 2014 at 03:44:53PM +0400, Dmitry Monakhov wrote:
> BTW where this can I find this discussion? I would like to cooperate
> this that activity. Please CC me next time you will disscuss allocation
> performance mesurments. At Parallels we run https://oss.oracle.com/~mason/compilebench/
> as load simulator.

The discussion happened at the Ext4 developer's get together in Napa,
California, colocated with the LSF/MM and the Collaboration Summit.
You should go next year; it was a huge amount of fun, and there were a
bunch of other Parallels people there who can tell you about the
reception at the Jacuzzi Family Winery, etc.  :-)

I suspect there will be some future conversations at our weekly
conference calls.  Typically design stuff will happen there, but
technical low-level details about things like patches will happen on
the mailing list, so you'll be alerted when we start having specific
patches to evaluate and as we start putting together a set of
allocation benchmarks.

If you are interested in participating on the conference calls,
contact me off-line.  If the current time (8AM US/Pacific ; 11 AM
US/Eastern) isn't good for you, we can try to see if another time
works for everyone.

One of the discussion points that came up last week is that it would
be good if we can come up with allocation tests that are fast to run.
That might mean (for example) taking a workload such as compilebench,
and changing it to use fallocate() or having a mount option which
causes the actual data path writes to be skipped for files.  We would
then need to have some kind of metric to evaluate how "good" a
particular file system layout ends up being at the end of the
workload.  Not just for a specific file, but for all of the files in
some kind of holistic measurement of "goodness", as well as looking at
how fragmented the free space ended up being.  Exactly how we do this
is still something that we need to figure out; if you have any
suggestions, they would be most welcome!

Cheers,

					- Ted

  reply	other threads:[~2014-04-01 14:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-02 16:32 [RFC PATCH 1/1] ext4: Try to better reuse recently freed space Lukáš Czerner
2013-12-04  5:21 ` Theodore Ts'o
2014-04-01  5:30 ` Theodore Ts'o
2014-04-01 11:44   ` Dmitry Monakhov
2014-04-01 14:47     ` Theodore Ts'o [this message]
2014-04-01 16:35       ` Dmitry Monakhov
2014-04-07 18:22   ` Andreas Dilger
2014-04-07 20:01   ` Andreas Dilger
2014-04-08  1:14   ` Andreas Dilger
  -- strict thread matches above, loose matches on Subject: below --
2013-07-04  9:11 [RFC PATCH 0/1] " Lukas Czerner
2013-07-04  9:11 ` [RFC PATCH 1/1] " Lukas Czerner
2013-07-04 15:09   ` Jan Kara
2013-07-04 15:32     ` Lukáš Czerner
2013-07-04 16:06       ` Jose_Mario_Gallegos

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=20140401144708.GT4911@thunk.org \
    --to=tytso@mit.edu \
    --cc=adilger@dilger.ca \
    --cc=dmonakhov@openvz.org \
    --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 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).