On Fri, 2006-12-05 at 09:35 -0500, Troy Benjegerdes wrote: > Have you tried making a read-only 'base' image and using qcow images > instead? I'm not convinced that splitting things up is going to help a > lot. You might end up writing 1 512 byte block each to 500 files.. in > the qcow image case, that is writing 256K, and with 10mb files, that's > 5GB.
The problem with this approach is that I get an ever-growing changes file which must eventually be merged (and then I have to copy the 20GB again). > at the very least, the console should print an error. If you can keep > all the files open, deleting the file won't be a problem. I agree -- console error should definitely occur. Opening all the files at the start is something to consider. It does fly in the face of two things, though: 1 -- Limiting the number of fds. Obviously opening all file parts at the very start will use up a whack of fds right away. 2 -- Not modifying files that haven't been modified. If you open a file read-write then its modification time is automatically updated and rsync will want to checksum/copy it again (it quickly checks local files based on modtime and size). If you open all files read-only then the file may not be there when you go to reopen it read-write. This is why the current implementation is as lazy as possible in terms of opening files. Cheers
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel