linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Hugo Mills <hugo@carfax.org.uk>,
	Nick Krause <xerofoify@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-btrfs@vger.kernel.org SYSTEM list:BTRFS FILE"
	<linux-btrfs@vger.kernel.org>
Subject: Re: Work Queue for btrfs compression writes
Date: Wed, 30 Jul 2014 10:13:29 -0400	[thread overview]
Message-ID: <20140730141329.GC20353@thunk.org> (raw)
In-Reply-To: <20140730093821.GJ31950@carfax.org.uk>

On Wed, Jul 30, 2014 at 10:38:21AM +0100, Hugo Mills wrote:
> qemu/kvm is good for this, because it has a mode
> that bypasses the BIOS and bootloader emulation, and just directly
> runs a kernel from a file on the host machine. This is fast. You can
> pass large sparse files to the VM to act as scratch disks, plus keep
> another smaller file for the guest OS (and a copy of it so that you
> can throw one away and make another one quickly and easily).

Nick,

The xfstests-bld/kvm-xfstests git tree I pointed out to you has an
example of a test infrastructure which does this for ext4.  It's been
on my todo list to support other file systems, and I have some plans
for how to do thi, but it's been low on my priority list.  If someone
in the btrfs development community is interested in working with me on
this, they should contact me.

Or the btrfs developers can create their own automated systems which
then gets promulgated, but either way, it's something that I strongly
recommend.  The set of test configs that ext4 developers would run
significantly increased after I cleaned up my test scripts and made it
something that other people could use, and it means that I can ask
people who are implementing new features that they run a complete
regression test run, with many different file systems features enabled
and disabled, so they find the problems before they propose a patch
for merging.

Cheers,

					- Ted



  reply	other threads:[~2014-07-30 14:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-30  3:54 Work Queue for btrfs compression writes Nick Krause
2014-07-30  9:38 ` Hugo Mills
2014-07-30 14:13   ` Theodore Ts'o [this message]
2014-07-30 14:36     ` Peter Hurley
2014-07-31 11:35       ` Theodore Ts'o
2014-07-30 15:36   ` ashford
2014-07-30 17:19     ` Nick Krause
2014-07-30 18:31       ` ashford
2014-07-30 19:40         ` Nick Krause
2014-08-04 13:29 ` Chris Mason

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=20140730141329.GC20353@thunk.org \
    --to=tytso@mit.edu \
    --cc=hugo@carfax.org.uk \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xerofoify@gmail.com \
    /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).