qemu-devel
[Top][All Lists]
Advanced

[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.

Attachment: block-multi.c
Description: Text Data

Attachment: qemu_multi.patch
Description: Text Data

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]