Re: [Qemu-devel] fat rw status

[Ivan Kalvachev]

2007/10/17, Ricardo Almeida <address@hidden>:
> Hi,
>
> I've sent a message 4 days ago but got no answer :(
>
> http://lists.gnu.org/archive/html/qemu-devel/2007-10/msg00314.html
>
> From:   Ricardo Almeida
> Subject:        [Qemu-devel] fat rw
> Date:   Sat, 13 Oct 2007 23:50:17 +0100
>
> Hi,
>
> I've found the fat:rw:dir option for harddrives and want to use it :)
> But when I run:
>
> qemu-system-x86_64 -kernel-kqemu -m 256 -hda winxp.qcow -hdb
> fat:rw:/media/lacie/
>
> I get:
>
> qemu: could not open hard disk image 'fat:rw:/media/lacie/'
>
> I've seen in qemu forums
> (http://qemu-forum.ipi.fi/viewtopic.php?p=12250) someone with a
> similar problem and the following solution:
>
> [QUOTE]
>  I am not sure this the correct solution, and I have no idea of what I
> am doing, but by changing the bdrv_create call in enable_write_target
> to:
>
>           Code:
>
>  if (bdrv_create(&bdrv_qcow,
>        s->qcow_filename, s->sector_count, NULL, 0) < 0)
>
>
>  This causes QEMU to start correctly and writes to the virtual disk
> work correctly.
> [/QUOTE]
>
> I'm using Kubuntu Gutsy with QEmu 0.9.0 from repository package with
> kqemu_1.3.0pre11, so "I can't" patch QEmu. I would like to know if
> this is already fixed on CVS or what's the current status.

Last time I tried to find out why :rw: didn't work I also came over this issue.
I also removed the "fat:" part and indeed I was able to start qemu
with fat:rw: and it did write to the virtual drive. What wasn't
happening was updating the host files. All changes to that virtual
drive are lost.

So the above change doesn't fix write support.

It probably have to do with the fact that the temporal image created
above must be snapshot of (another) block_vvfat, then the original
vvfat hijacks the 2'd vvfat and tries to place its routines
there....(and if there is no slave block device the writes would never
be piped to vvfat). It's very hackish and very broken (I think cow
driver always looks for file, so it tries to open "/tmp/fat:" instead
and always fails).

One possible solution is to special case the "fat:" opening. Or to
make main block code to always create the temporal snapshot device
before original vvfat creation (and not create second in case of
snapshot). Still the vvfat would have to access it directly... that is
still quite hackish, snapshots would still would need special
handling.

Another solution is to remove all hacks, fat:rw just creates temporal
image and doesn't try to (re)use any automatic snapshot functionality.
The block writes that vvfat cannot process will have to be stored in
the temp image manually, and eventually to be found, read and freed
when they can finally be processed and written on the host.
I think this is the cleanest solution.

Anyway, At that time, I decided it would take me quite too much time
to properly fix it, so I left it after I finish my current project. I
guess in week or two I may have some free time. (Of course the
original author would be able to fix it faster, as he is already quite
familiar with the code).