On Fri, 2006-12-05 at 22:21 +0200, Flavio Visentin wrote:
> OT for qemu, but if you use *rsync*, then only the changed part of the
> file are copied, not all the file. Rsync was written just for this
> reason, to avoid copying unneccessary unchanged data.
But as soon as the modification stamp chan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ryan Lortie wrote:
> I use rsync to backup my home directory. The act of starting up QEMU
> changes a 20GB file on my drive. This causes 20GB of extra copying next
> time I do backups.
OT for qemu, but if you use *rsync*, then only the changed part
Hi there,
> o If the files comprising the device are deleted (for example) while
>QEMU is running then this is quite bad. Currently this will result
>in read/write requests returning -1. Maybe it makes sense to panic
>and cause QEMU to exit.
>
at the very least, the console shoul
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,
On Thu, May 11, 2006 at 02:30:45AM -0400, Ryan Lortie wrote:
> Hello.
>
> Attached is a C file (and small patch) to add support for multi-file raw
> images to QEMU. The rationale (for me at least) is as follows:
>
> I use rsync to backup my home directory. The act of starting up QEMU
> changes
Hello.
Attached is a C file (and small patch) to add support for multi-file raw
images to QEMU. The rationale (for me at least) is as follows:
I use rsync to backup my home directory. The act of starting up QEMU
changes a 20GB file on my drive. This causes 20GB of extra copying next
time I do
