amphetamachine's questions

I've been using a QEMU system to build software. The problem I've been having is that the system seems to suffer from extremely slow disk access. This is not necessarily a problem as it's not really a time-intensive operation, but I'd like to have it work as fast as possible.

Here's all I've done to attempt to speed up I/O:

• KVM is enabled. This is the difference between night and day as far as emulated processor speed is concerned.

• Qemu is run with -display none mode through a forwarded SSH port, so there's no emulated SDL display eating CPU cycles.

• The virtual hard drives are mounted with -o noatime,nodiratime to cut down on unnecessary writes.

• The hard disk images (8 and 12 gigs respectively) are in qcow2 format and were created with -o cluster_size=2M (this is the maximum–default is 65,536 bytes). Quoth the man page: "Smaller cluster sizes can improve the image file size whereas larger cluster sizes generally provide better performance."

• The filesystem is EXT4 with the -o extents option, which the man page claims "is a much more efficient encoding which speeds up filesystem access, especially for large files."

• The virtual disk images do not have any snapshots stored in them. I am unsure whether this would slow them down, but it seems like it would; the actual file image size does not grow when a snapshot is recorded, so my guess is that the data is stored in some convoluted way that makes it so the snapshot and the "working" drive will share a cluster until it is changed, then the entire 2 MB cluster is copied into new space, then the data is changed. Ingenious but totally inefficient.

My question is whether there is anything I'm missing to increase hard disk efficiency, or what has worked for people in the past in order to achieve near-native I/O speeds.

Here are a couple of other things that I have observed:

• When I mount the hard drive in the virtual host with -o sync the system slows way down. This seems counter-intuitive to me since the writes to the virtual hard drive, which is just a file on my actual hard drive, are already buffered in RAM before written. This is essentially double buffering to the disk, using twice as much RAM as it has to. The dramatic speedup is especially strange since doing a grep ^Dirty /proc/meminfo never says anything over 1 MB.

• The virtual machine seems to refuse to use its swap unless I set the "swappiness" (/proc/sys/vm/swappiness) to 90 or higher. While I agree this is probably a good thing in terms of disk I/O, it makes the build processes "fight" with the fs buffering for use of the RAM. Yes, I'm sure it has enough RAM.

What is the general rule for which daemons should be started up through inetd? Currently, on my server, sshd, apache and sendmail are set up to run all the time, where simple *NIX services are set up to be started by inetd.

I'm the only one who uses ssh on my computer, and break-in attempts aren't a problem because I have it running on a non-standard port, and my HTTP server gets maybe 5 hits a day that aren't GoogleBot.

My question is, what are the benefits vs. the performance hits associated with running a complex daemon like sshd or apache through a superserver daemon, and what, if any, successes or failures have you had running your own daemons in this manner?

I recently did something stupid on my dual-boot laptop, where I compressed the entire volume to make room for a Linux partition. For some reason, Windows let me compress C:\ntldr. Now I need to get it uncompressed in order for Windows to boot.

Here are some of the operating restrictions I have:

• I do not have access to the BIOS.
• I cannot boot from CD/USB/floppy. (I installed Linux through PXE)
• It does not have network access.

Is there were some way to specify that the ntfs-3g driver shouldn't compress files even if it thinks it should (if the directory is compressed) when mounting the volume?

Or, is there a way to modify the attributes of a directory using ntfsprogs?