Bug#600056: qemubuilder: low read/write performance on qemu block devices

2011-04-22 Thread Mike Gabriel

Hi Benoit,

thanks a lot for these patches. I have rebuilt the cowdancer package  
and now the performance is awesome when building packages with  
qemubuilder...


@Junichi Uekawa San: any chance that these patches get included into  
the official qemubuilder source?


Greets+Thanks,
Mike

--

DAS-NETZWERKTEAM
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419

GnuPG Key ID 0xB588399B
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgpW7vEsxZHPD.pgp
Description: Digitale PGP-Unterschrift


Bug#600056: qemubuilder: low read/write performance on qemu block devices

2011-04-05 Thread Agustin Martin
On Mon, Apr 04, 2011 at 04:57:46PM +0200, Agustin Martin wrote:
 On Wed, Oct 13, 2010 at 11:08:23AM +0200, Benoît Knecht wrote:
  The last patch replaces ext3 with ext2 for the image filesystem, which
  should be faster because it doesn't need to write transactions in the
  journal.
 
 With this change I had some problems. Did not really investigate, but I get
 
 Loading, please wait...
 
  - qemu-pbuilder first-stage
 mount: proc already mounted
 [   79.649780] ext3: No journal on filesystem on sdb
 mount: wrong fs type, bad option, bad superblock on /dev/sdb,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail  or so
 
 I may need to refresh some things in orginal qemubuilder image.

As expected, recreating qemubuilder initial image with your ext2 patch
applied made thinks work. Did not get accurate timings, but seems indeed to
be faster than using ext3.

Since this change can cause old images to stop working, may be is
interesting to put it as a documented configurable option, so when reading
documentation, users know what to do. Do not know what upstream thinks
about this.

For now I will stay for my personal use with a patched qemubuilder with
your three patches applied. Will let you know if I find further problems.

Your patches were really useful, thanks a lot.

Regards,

-- 
Agustin



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#600056: qemubuilder: low read/write performance on qemu block devices

2011-04-04 Thread Agustin Martin
On Wed, Oct 13, 2010 at 11:08:23AM +0200, Benoît Knecht wrote:
 Package: qemubuilder
 Version: 0.62
 Severity: normal
 Tags: patch
 
 I'm using qemubuilder to emulate an armel system on an amd64 machine.
 The speed of the block devices in the emulated environment is terribly
 low (packages are downloaded at a few hundred bytes per second only, and
 reading the package database takes forever). This leads to lots of
 lsi_scsi: error: Unimplemented message 0x0c and task kjournald:22 blocked
 for more than 120 seconds. errors, and a very slow building process.

Hi,

I am also having problems with disk performance when emulating an amd64
builder in a real i386 box. Disk access becomes terribly slow with some of 
those 'blocked for more than 120 seconds' messages and DMA errors, making 
my amd64 builder unusable in practice.

 I'd like to propose the following three patches, that greatly improved
 performance in my case (maybe other setup won't see such a big
 performance improvement, but I don't think these changes can reduce
 performance in any case).
 
 The first patch makes qemu use writeback instead of writethrough for
 caching, and gets rid of the lsi_scsi and blocked for more than 120
 seconds errors.
 
 The second patch creates qcow2 images instead of the deprecated qcow, as
 it is supported since qemu-0.8.3.

Tested with these two first patches applied. Big success, thanks a lot. 

While system is still slow, there is no trace of 'blocked for more than 
120 seconds' nor DMA error messages.

 The last patch replaces ext3 with ext2 for the image filesystem, which
 should be faster because it doesn't need to write transactions in the
 journal.

With this change I had some problems. Did not really investigate, but I get

Loading, please wait...

 - qemu-pbuilder first-stage
mount: proc already mounted
[   79.649780] ext3: No journal on filesystem on sdb
mount: wrong fs type, bad option, bad superblock on /dev/sdb,
   missing codepage or helper program, or other error
   In some cases useful info is found in syslog - try
   dmesg | tail  or so

I may need to refresh some things in orginal qemubuilder image.

Anyway, thanks a lot. First two changes at least make me have a minimally
working amd64 qemubuilder image.

Regards,

-- 
Agustin



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#600056: qemubuilder: low read/write performance on qemu block devices

2010-12-14 Thread Ying-Chun Liu (PaulLiu)
Hi.

Thanks for the patch. I haven't try all of them but this bug also
appears on armel system when --update. I get several lsi_scsi: error:
Unimplemented message 0x0c and then some task kjournald:22 blocked
for more than 120 seconds. and then the kernel oops.

After applying 0001-Use-writeback-caching-for-qemu-disks.patch
qemubuilder just works very well.

Many Thanks,
Paul




signature.asc
Description: OpenPGP digital signature


Bug#600056: qemubuilder: low read/write performance on qemu block devices

2010-10-13 Thread Benoît Knecht
Package: qemubuilder
Version: 0.62
Severity: normal
Tags: patch

I'm using qemubuilder to emulate an armel system on an amd64 machine.
The speed of the block devices in the emulated environment is terribly
low (packages are downloaded at a few hundred bytes per second only, and
reading the package database takes forever). This leads to lots of
lsi_scsi: error: Unimplemented message 0x0c and task kjournald:22 blocked
for more than 120 seconds. errors, and a very slow building process.

I'd like to propose the following three patches, that greatly improved
performance in my case (maybe other setup won't see such a big
performance improvement, but I don't think these changes can reduce
performance in any case).

The first patch makes qemu use writeback instead of writethrough for
caching, and gets rid of the lsi_scsi and blocked for more than 120
seconds errors.

The second patch creates qcow2 images instead of the deprecated qcow, as
it is supported since qemu-0.8.3.

The last patch replaces ext3 with ext2 for the image filesystem, which
should be faster because it doesn't need to write transactions in the
journal.

These patches should apply cleanly on cowdancer-0.62 with the fixes for
bugs #564425 and #597102 already applied.

-- 
Benoît Knecht
By default, qemu uses writethrough caching, which is more reliable in
case the host crashes, but less performant.
---
 qemubuilder.c |   16 
 1 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/qemubuilder.c b/qemubuilder.c
index 2086f09..6c8c27f 100755
--- a/qemubuilder.c
+++ b/qemubuilder.c
@@ -268,6 +268,8 @@ static int fork_qemu(const char* hda, const char* hdb, const struct pbuilderconf
   /* this is the child process */
   const char* qemu = qemu_arch_qemu(pc-arch);
   const char* machine = qemu_arch_qemumachine(pc-arch);
+  char* hda_command;
+  char* hdb_command;
   char* append_command;
   const char* kernel_image = pc-kernel_image;
   const char* initrd = pc-initrd;
@@ -284,6 +286,12 @@ static int fork_qemu(const char* hda, const char* hdb, const struct pbuilderconf
 
   asprintf(mem, %i, pc-memory_megs);
 
+  asprintf(hda_command, file=%s,index=0,media=disk,cache=writeback,
+	   strdupa(hda));
+
+  asprintf(hdb_command, file=%s,index=1,media=disk,cache=writeback,
+	   strdupa(hdb));
+
   asprintf(append_command,
 	   root=/dev/%sa quiet init=/pbuilder-run console=%s,
 	   qemu_arch_diskdevice(pc),
@@ -307,10 +315,10 @@ static int fork_qemu(const char* hda, const char* hdb, const struct pbuilderconf
 	  argv[argc++]=-initrd;
 	  argv[argc++]=strdupa(initrd);
 	}
-  argv[argc++]=-hda;
-  argv[argc++]=strdupa(hda);
-  argv[argc++]=-hdb;
-  argv[argc++]=strdupa(hdb);
+  argv[argc++]=-drive;
+  argv[argc++]=hda_command;
+  argv[argc++]=-drive;
+  argv[argc++]=hdb_command;
   argv[argc++]=-append;
   argv[argc++]=append_command;
   argv[argc++]=-serial;
qcow is deprecated, and qcow2 has been supported by qemu since 0.8.3
(which is fine even for lenny).
---
 qemubuilder.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/qemubuilder.c b/qemubuilder.c
index 6c8c27f..78656f6 100755
--- a/qemubuilder.c
+++ b/qemubuilder.c
@@ -489,7 +489,7 @@ static int run_second_stage_script
   ret=forkexeclp(qemu-img, qemu-img,
 		 create,
 		 -f,
-		 qcow,
+		 qcow2,
 		 -b,
 		 pc-basepath,
 		 cowdevpath,
Ext3 writes transactions to a journal, which is quite slow on an
emulated disk. Since we don't really need a journal (if anything goes
wrong, the image can easily be recreated), use ext2 instead.
---
 qemubuilder.c |   13 ++---
 1 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/qemubuilder.c b/qemubuilder.c
index 78656f6..eec8afa 100755
--- a/qemubuilder.c
+++ b/qemubuilder.c
@@ -47,14 +47,14 @@
  */
 const char* qemu_keyword=END OF WORK EXIT CODE=;
 
-/** create a sparse ext3 block device suitable for
+/** create a sparse ext2 block device suitable for
 loop-mount.
 
 This code takes approx 7 seconds to run, should be cached?
 
@returns -1 on error, 0 on success
  */
-static int create_ext3_block_device(const char* filename,
+static int create_ext2_block_device(const char* filename,
 unsigned long int gigabyte)
 {
   int ret = 0;
@@ -72,7 +72,6 @@ static int create_ext3_block_device(const char* filename,
   if ((ret=forkexeclp(mke2fs, mke2fs,
 		  -q,
 		  -F,
-		  -j,
 		  -m1,
 		  -O, sparse_super,
 		  filename, NULL)))
@@ -419,7 +418,7 @@ static int run_second_stage_script
   timestring=get_current_time_string();
 
   asprintf(workblockdevicepath, %s.dev, pc-buildplace);
-  ret=create_ext3_block_device(workblockdevicepath, 1);
+  ret=create_ext2_block_device(workblockdevicepath, 1);
   loop_mount(workblockdevicepath, pc-buildplace);
 
   f = create_script(pc-buildplace, pbuilder-run);
@@ -613,7 +612,7 @@ int cpbuilder_create(const struct