Elmar Haneke wrote:
>> Also, I haven't had the time yet to work on it, but I was thinking about
>> a "growable" harddisk (so if you create a new harddisk image with size 2
>> Gig, you'll end with an initial harddisk file of a couple of Kb's that
>> "grows" as soon as something is written to a sector.)
>
>I would expect this feature to be of limited enhancement since
>DOS/Windows cetrainly will write to many sectors on disk.
Hello,
I've been following the message archives for plex86 for a while; mostly I've
been kinda bewildered by it all. The subject of the hard drive simulation,
though, is something to which I feel I can contribute some potentially
useful ideas, particularly regarding this idea of having a 'growable'
hardfile. I thought I may as well post them.
Since a hard drive is being simulated by plex86 anyway, it wouldn't be too
difficult to overcome the FAT/NTFS system of writing to clusters anywhere on
the disk; I imagine it's feasible with *nix-style filesystems, too. At least
until reiserfs/ext3 et al become the norm.
I submit two methods for consideration:
1) Assign clusters on a 'per-use' basis, in a consecutive fashion.
This would result in clusters being in the wrong order in the hardfile, but
the guest would see the disk image in the correct manner. A plex86 host-side
drive mapping bitmap would be necessary to keep track of it all. A separate
tool would be made available to 'defragment' this file, so that while great
stretches of the partition wouldn't exist, at least those clusters that do
exist would be in the correct order. Perhaps the plugin could note, at
startup, that the simulated partition is >15% fragmented, and suggest that
the offline defragmenter be run before trying to do anything disk intensive
in the guest?
2) Split the hardfile into more manageable chunks.
By this, I mean that for (for example) a 2gb guest 'partition', have 20
files on the host disk, each of 102mb, plus a 15-20mb 'journal'. Initially,
create each of the files as 0-length (or just don't create them). Then, as
the guest writes to clusters in the different files, either a) write
directly to the file, if it exists, or b) write to the journal, and flag
that the required partition block needs to be created during an 'idle'
period (or when the journal becomes full). Using this 'delayed creation'
technique would help to avoid the guest OS locking up at important moments
as the host hurries to create a file to write in.
Neither method would work if true (or 'direct') simulation were implemented,
since DOS/Windows require that the partition be formatted before use. Would
it, therefore, be possible to trap the various methods used to format a
cluster/sector, and just not do it (but return success, of course)? The
FAT(s), or MFT, would still be written, etc, and so the guest would be
unaware.
A further nice extension to hard drive simulation would be (if a non-direct
simulation method were chosen) to compress the hardfile's simulated
'clusters', thus further reducing the disk requirement of the guest OS's.
Of course, everything I've mentioned here involves (significantly, I
imagine) more work in the plugin, and certainly would reduce performance; an
advantage of the plex86 plugin architecture would be that the user chooses
the performance:space ratio that best pleases them.
I would like to say that I'd write (or at least investigate) these ideas
further, in the context of plex86, but I have little motivation to code
outside my working hours at the moment.
Thanks for listening,
Nik Borton
Software engineer, Thermo Elemental (Winsford)
mailto:[EMAIL PROTECTED]
http://www.tjasolutions.com
"The opinions expressed here are those ... blah blah, yakkity schmakkity ...
"
