Runner

Share

I bought this book on impulse, and I am glad I did. The book is very Buddhist in its outlook, and characters believe in reincarnation, which makes it ok for people to die. There sure is a lot of that happening in this book, perhaps more so than in Dietz’s combat books. The underlying story is very different from the other Dietz stuff I have read, and very good. The Legion of the Damned books suffer from very one dimensional characterizations of their female characters, whereas this book has a strong female as a leading and fully developed character, which is a nice change. I enjoyed this book.

[isbn: 9780441014095]

Share

Red Storm Rising

Share

I had read this book many years ago, and remembered it fondly. I wasn’t disappointed reading it again — its certainly a classic techno-thriller, even if it is a little dated now. I imagine it would make less sense to someone who hadn’t grown up with the cold war, but within that context its a good read. The worst bit is that given what we knew back then it is so completely plausible. Great book.

[isbn: 0006173624;9780006173625]

Share

Rise of a Merchant Prince

Share

I didn’t really like this book, but I persisted with it because I want to keep reading the series. I thought the previous Serpent War book Shadow of a Dark Queen was weak, but this book was weaker. The book follows the rise of Roo as a merchant, and is improbable at best — Roo’s wealth is generated by cornering the food market for Krondor and I see weaknesses in the analysis there — surely the Duke wouldn’t allow such a manipulation of the market when it harms his citizens, why weren’t there food riots when the cost of basic staples jumped to record levels overnight? Basically, it just doesn’t seem believable to me.

The sequence at the panthian lair on the other hand is much better, and the best bit of the book. Its a pity it is only about 50 pages long.

[isbn: 0006497012;0071001007992;0380720876]

Share

Wow, qemu-img is fast

Share

I wanted to determine if its worth putting ephemeral images into the libvirt cache at all. How expensive are these images to create? They don’t need to come from the image service, so it can’t be too bad, right? It turns out that qemu-img is very very fast at creating these images, based on the very small data set of my laptop with an ext4 file system…

    mikal@x220:/data/temp$ time qemu-img create -f raw disk 10g
    Formatting 'disk', fmt=raw size=10737418240
    
    real	0m0.315s
    user	0m0.000s
    sys	0m0.004s
    
    mikal@x220:/data/temp$ time qemu-img create -f raw disk 100g
    Formatting 'disk', fmt=raw size=107374182400
    
    real	0m0.004s
    user	0m0.000s
    sys	0m0.000s
    

Perhaps this is because I am using ext4, which does funky extents things when allocating blocks. However, the only ext3 file system I could find at my place is my off site backup disks, which are USB3 attached instead of the SATA2 that my laptop uses. Here’s the number from there:

    $ time qemu-img create -f raw disk 100g
    Formatting 'disk', fmt=raw size=107374182400
    
    real	0m0.055s
    user	0m0.000s
    sys	0m0.004s
    

So still very very fast. Perhaps its the mkfs that’s slow? Here’s a run of creating a ext4 file system inside that 100gb file I just made on my laptop:

    $ time mkfs.ext4 disk
    mke2fs 1.41.14 (22-Dec-2010)
    disk is not a block special device.
    Proceed anyway? (y,n) y
    warning: Unable to get device geometry for disk
    Filesystem label=
    OS type: Linux
    Block size=4096 (log=2)
    Fragment size=4096 (log=2)
    Stride=0 blocks, Stripe width=0 blocks
    6553600 inodes, 26214400 blocks
    1310720 blocks (5.00%) reserved for the super user
    First data block=0
    Maximum filesystem blocks=0
    800 block groups
    32768 blocks per group, 32768 fragments per group
    8192 inodes per group
    Superblock backups stored on blocks:
    	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    	4096000, 7962624, 11239424, 20480000, 23887872
    
    Writing inode tables: done
    Creating journal (32768 blocks): done
    Writing superblocks and filesystem accounting information: done
    
    This filesystem will be automatically checked every 36 mounts or
    180 days, whichever comes first.  Use tune2fs -c or -i to override.
    
    real	0m4.083s
    user	0m0.096s
    sys	0m0.136s
    

That time includes the time it took me to hit the ‘y’ key, as I couldn’t immediately find a flag to stop prompting.

In conclusion, there is nothing slow here. I don’t see why we’d want to cache ephemeral disks and use copy on write for them at all. Its very cheap to just create a new one each time, and it makes the code much simpler.

Share

Slow git review uploads?

Share

jeblair was kind enough to help me debug my problem with slow “git review” uploads for Openstack projects just now. It turns out that part of my standard configuration for ssh is to enable ControlMaster and ControlPersist. I mostly do this because the machines I use at Canonical are a very long way away from my home in Australia, and its nice to have slightly faster connections when you ssh to a machine. However, gerrit is incompatible with these options as best as we can tell.

So, if your git reviews are taking 10 to 20 minutes to upload like mine were, check that you’re not using persistent connections. Excluding review.openstack.org from that part of my configuration has made a massive difference to the speed of uploads for me.

Share