Full Linux Mint (17.1) Installation with writeback: With VDI extra sync 4min35s Vanilla: 3min17s
which is consistent with 'qemu-img convert' (slightly less overhead due to some phases in installation is actually CPU bound). Still much faster than other "sync-after-metadata" formats like VPC (vanilla VPC 7min43s) The thing is he who needs to set up a new Linux system every day probably have pre-installed images to start with, and others just don't install an OS every day. On Sat, May 9, 2015 at 2:39 PM Stefan Weil <s...@weilnetz.de> wrote: > Am 09.05.2015 um 05:59 schrieb phoeagon: > > BTW, how do you usually measure the time to install a Linux distro within? > Most distros ISOs do NOT have unattended installation ISOs in place. (True > I can bake my own ISOs for this...) But do you have any ISOs made ready for > this purpose? > > On Sat, May 9, 2015 at 11:54 AM phoeagon <phoea...@gmail.com> wrote: > >> Thanks. Dbench does not logically allocate new disk space all the time, >> because it's a FS level benchmark that creates file and deletes them. >> Therefore it also depends on the guest FS, say, a btrfs guest FS allocates >> about 1.8x space of that from EXT4, due to its COW nature. It does cause >> the FS to allocate some space during about 1/3 of the test duration I >> think. But this does not mitigate it too much because a FS often writes in >> a stride rather than consecutively, which causes write amplification at >> allocation times. >> >> So I tested it with qemu-img convert from a 400M raw file: >> zheq-PC sdb # time ~/qemu-sync-test/bin/qemu-img convert -f raw -t unsafe >> -O vdi /run/shm/rand 1.vdi >> >> real 0m0.402s >> user 0m0.206s >> sys 0m0.202s >> zheq-PC sdb # time ~/qemu-sync-test/bin/qemu-img convert -f raw -t >> writeback -O vdi /run/shm/rand 1.vdi >> > > > I assume that the target file /run/shm/rand 1.vdi is not on a physical > disk. > Then flushing data will be fast. For real hard disks (not SSDs) the > situation is > different: the r/w heads of the hard disk have to move between data > location > and the beginning of the written file where the metadata is written, so > I expect a larger effect there. > > For measuring installation time of an OS, I'd take a reproducible > installation > source (hard disk or DVD, no network connection) and take the time for > those parts of the installation where many packets are installed without > any user interaction. For Linux you won't need a stop watch, because the > packet directories in /usr/share/doc have nice timestamps. > > > Stefan > >
