Hi Willow,
Thanx for looking into it, remarks between the lines.
On 26 Feb 2001, (regarding Re: [plex86] Please help the newbie)
Willow Schlanger wrote:
> Nice job! What version of VMWare are you using? Did you check to see if
> the source code that comes with the Linux distribution of VMWare (came
> with my version anyway) has the source code for reading/writing to the
> disk images?
Using build 799, 2.0.3, trial for win32.
Does the source come with the Linux-version? I doubt it, at least not
with mine, just some kernelversion dependent stuff, but you might
want to check.
Note for other people: these sources are all (c) VMWare - except
the user-space parport stuff (Tim Waugh) - so if you're concerned
you might be accusued of stealing code: do not open the files
(there's no license.txt with it).
> The format I mentioned earlier might be better, however:
Sorry.. just started reading Jan 3..
> Let's say your linux partition is 1GB, and you want to make a disk image
> but you aren't sure how big to make it.
> [ ... cut ... ]
Well.. 1 GB max I'd say.. ;-)
> - This has the benifiet of only allocating disk space for sectors
> (actually clusters) that are really used.
> - Unlike the VMWare format, this does not require you to decide in
> advance how much you might use as a maximum. By using a different file
> for the index, the number of indexes can grow as necessary.
You're overlooking one important issue here: it should be
transparant to the guest-OS, so having diskparameters vary
between sessions doesn't make sense. There's also the
partitioning of this virtual disk, that is of no concern to the host (from
the virtual aspect that is), but limits the guest to use only defined
partitions, falling within the phys params.
However, there is a very good point in your remark: users (and me
too) want to be able to change disksizes after creation!
This doesn't have to be dynamic, as for most practical purposes
this doesn't happen every day, so a seperate conversion-utility
would be sufficient.
Another advantage: you get a backup for free ;)
> - It did not occurr to me to use a third level. Seems quite useless.
I'm not sure yet, but I think it makes sense. Since the location
(physical, host) where new (logical, guest) sectors are written (=
appended) will normally be near the sectors containing the 3rd
level, you gain performance. Furthermore, as I think of it, one might
be able to let the host do some journalling, by writing to a copy of
the leaf, submitting the leaf to the branch on flush, but I hope I'll get
back to write-alghoritms later on.
> (.. mathematics cut ...)
Maths are almost identical for the VMWare format.
> We should use some kind of compression like this: if all bytes of all
> sectors of a cluster are the same, then when more clusters are made that
> contain completely the exact same byte, make it POINT to the former one.
Err.. And what if 'the former' is changed? Do they all change?
Where's the referencecount? Which impact would it have on
performance? Is the gain in disk worth those losses? I wouldn't like
such a format: is one thing to write smart, is's another to make
things complicated.
Smart writing would be to have not one, but two empty-sector defs:
zeroed and formatted. Yet better: I have not looked into formatting
recently, but if I remember correctly, that's done by the BIOS / int13,
isn't it? So let's have that routines write zeroes or abort the format.
> I just thought of something! This is pointless if we use some kind of
> disk compression. Does Linux support it? I think 2000 does but I'm not
> sure.
Windows 2000 can and I remember Linux can too. But this time
complications are up to the user, not the driver, which is OK.
> How to WRITE. Eventually the user will write to a sector for the first
> time. This will mean GROWING the data file and index file at first. We
> could do that right now: make it so that the disk image file
> automatically grows. I bet it already does that for DOS.
It does. And that's the reason for this discussion, isn't it?
> But what if the user deletes a 200MB file? If we use intelligence, we
> could monitor all disk accesses and if we tell the monitor what
> filesystem we are using, then direct disk accesses could be conterted
> more or less to host-level file operations. This would be especially
> easy for the FAT filesystem. Then if a 200MB file gets deleted that much
> disk space would become available to the host as well as the guest; thus
> also to other guests.
Much simpler: supply or use a diskwiper (for free space only that is
;).
[ .. examples and numbers cut ... ]
>
> As for using VMWare's format:
>
> I could help you out, as I know C and C++ but to learn more about the
> format I'd need to get Linux running *inside* bochs. I don't know enough
> about Linux to make a distrubtion that can compile itself and run
> VMWare, unfortunately, however.
?? Not sure what you mean.
However, I think Delphi and Kylix are excellent choices to write a
standalone GUI-based conversion/exploration tool. As a matter of
fact, reading vmware format seems to be done. *smile*
Regards,
Paul
>
> [snip]
> > Here's a Delphi listing of the header-record.
> > A LongWord is a UINT32
> >
> > TVMBootRec = packed record
> > // Magic: always 'COWD' or 1146572611, stands for COWDisk (where COW is ...?)
> > Magic: array[0..3] of Char;
NB: for now, COWDisk stands for Create (Construct) On Write-
Disk, I think.
----
Paul te Bokkel
Sphere Information Technologies BV
PGP key available and PGP preferred
