qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Looking for an easy way to exchange data bidirectional


From: Henrik Nordstrom
Subject: Re: [Qemu-devel] Looking for an easy way to exchange data bidirectional between host and guest (including some suggestion)
Date: Thu, 9 Jun 2005 13:48:34 +0200 (CEST)

On Wed, 8 Jun 2005, Johannes Schindelin wrote:

There is several big issues involved in providing write support

a) On guest writes, the emulation must have a very good understanding of
how the guest writes to the emulated filesystem to allow it to piece
together the block level writes and map this to the files it is supposed
to represent on the host.

No. It MUST NOT have a ver good understanding of the guest writes, because
different OSes have different write strategies. The block driver MUST be
agnostic to this. That is what makes write-support so hard.

Exacly, which to me is the same thing ;-)

(having a very good understanding automatically gives the conclusion that the data is mainly written in block level order by the elevator, not filesystem structure order)

b) On host writes it must detect changes in the directory and reflect this
into the block level filesystem structure. You also have to battle with
filesystem and block level caches in the guest to make the guest see the
updated block level filesystem structure.

That is the main problem. Basically, in FAT a file gets written in three
stages: the directory entry is modified, the block list (in the File
Allocation Table) is adapted, and the actual data is written into the
blocks. Now, a seemingly good heuristic would find in which order these
entries are written, right? Wrong: The caching more often than not makes
this infeasible. While the OS really writes the three stages in the same
order, it does so only to the cache. And which cached blocks get written
out first is quite deliberate. Linux uses (very limited) caching on
floppies, too.

Eh, I am talking about writes from the host side here. But what you write is a very accurate description of problem 'a' (understanding of how the guest writes to the FS and piece the writes together to allow mapping them back the the host files).

What I tried to refer to here is that vvfat if supporting writes from the host side it must monitor the mapped directory and on each host side initiated change of any kind (write to file, addition/removal of file, new subdirectory, timestamp change etc) simulate a "change floppy" event, and rebuild it's emulated fat structure from the host directory.

Regards
Henrik




reply via email to

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