[Xen-bugs] [Bug 1660] New: Usage of dd in xen-create-image release 4.2rc1 - CVS: 192 could be optimised

[bugzilla-daemon@xxxxxxxxxxxxxxxxxxx]

http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1660

           Summary: Usage of dd in xen-create-image release 4.2rc1 - CVS:
                    192 could be optimised
           Product: Xen
           Version: unstable
          Platform: x86-64
        OS/Version: Linux-2.6
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Tools
        AssignedTo: xen-bugs@xxxxxxxxxxxxxxxxxxx
        ReportedBy: andre.d@xxxxxxx
                CC: andre.d@xxxxxxx


Hello there,

I have fixed my PV Linux 2.6.32.21 Dom0 to 384MB as an experiment, because I am
a fan of systems which run with a predictable amount of resources.

I ran into trouble upon creating a large (full) loopback image on my SW RAID-1.
High system load for a long time.

I had a look at /usr/bin/xen-create-image and figured it uses, for sparse and
full images, respectively:

$image_cmd = "dd if=/dev/zero of=$disk bs=$size count=0 seek=1024";
$image_cmd = "dd if=/dev/zero of=$disk bs=$size count=1024";

I changed the full image creation to

$image_cmd = "dd if=/dev/zero of=$disk bs=1024 count=$size";

and it not only outperformed the original at 139% real time data throughput of
the original statement. It also showed reasonable memory consumption by dd and
a low CPU load, as opposed to the distribution's approach.

YMMV but I don't see a point in forcing dd to allocate a huge block size, when
the same task can be achieved with a reasonable one which serves the needs of
limited resource availability better?


-- 
Configure bugmail: 
http://bugzilla.xensource.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

_______________________________________________
Xen-bugs mailing list
Xen-bugs@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-bugs