tg%gmplib.org@localhost (Torbjörn Granlund) writes: > This actually sounds like a plausible explanation. Thank you! > > I've seen Dom0 CPU usage go up inexplicably for certain DomU file > operations. Usually the systems stabilise after having been frozen for > perhaps a dozen seconds. I recall that I some years ago stopped using > sparse files under NetBSD, but I cannot recall the details of what led > me to do that. > > The new disastrous problem happened when I used a 20 GB sparse file > (yes, qemu-img-xen creates sparse files); all images used for this > system were just 1 GB to 2 GB. Perhaps size matters? I think the basic issue is that a write arriving at the vnd which then needs to do fs ops to allocate a block can hang. But I'm really unclear on the details. > I'll try and find time for some experiments. (I will need to remove the > system from the co-location site.) I'm not sure why you want to experiment :-) Seriously, on a production machine, I would recommend just making all files used for vnd non-sparse. (If you want to grab another box to experiment on a home to fix the bug, great, but I would decouple that from your production setup.) Another reason not to use sparse files is that creating files non-sparse gets you pretty good locality of block allocation and I think this leads to higher efficiency, but I don't have test data. So I'd just copy each image file with dd, and then rm the old one and rename. As in just: dd if=image of=image.new bs=1m mv image image.sparse mv image.new image and then delete image.sparse when you are confident. (note to self: fix the howto to explain this!) Greg
Attachment:
pgpn90J4slNTi.pgp
Description: PGP signature