[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] PATCH: Support for multi-file raw images
From: |
Ryan Lortie |
Subject: |
[Qemu-devel] PATCH: Support for multi-file raw images |
Date: |
Thu, 11 May 2006 02:30:45 -0400 |
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 backups. If I could split the drive image into smaller parts
(maybe 2048 10MB files) then the amount of extra copying is drastically
reduced (since only a few of these files are modified).
There are definitely other reasons that this may be useful.
It works as follows:
1) Create a bunch of files of equal size with names of the form
harddriveXX
where XX is a hex number starting from 00 going to whatever.
NB: you can have any number of XXs from 0 (ie: basically a single-file
image) to 6 (ie: up to 16 million parts).
2) Run qemu multi:harddrive000
QEMU will detect the multi-part image, do a sanity check to ensure all
the parts are there, of the same size, and accessible and then start
using the device as the harddrive (this consists of calling 'stat' and
'access' on each file).
Some notes:
o I've tested only on Linux. I'm positive the code is not portable
to other systems. Feedback about this, please.
o Included is optional support for limiting the number of open fds.
Cache eviction is done using a least-recently-opened policy
(efficiently implemented using a ring buffer).
o The code makes use of the euidaccess() syscall which is Linux-only.
BSD has eaccess() to do the same thing. Both of these calls are
approximately equal to POSIX access() except that the euid of the
process is considered instead of the real uid. The call is used
to determine if the device should be marked 'read_only' by checking
for write access to the files comprising the device. If access()
is used and QEMU is installed setuid/gid to give the user access to
a drive image then the result of using access() will be that the
drive is incorrectly flagged read-only.
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.
o All comments welcome.
Cheers.
block-multi.c
Description: Text Data
qemu_multi.patch
Description: Text Data
signature.asc
Description: This is a digitally signed message part
- [Qemu-devel] PATCH: Support for multi-file raw images,
Ryan Lortie <=