I've dumped some comments into this....., please have a look.....
Drew Northup, N1XIM
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
> Of Nik Borton
> Sent: Wednesday, October 18, 2000 7:21 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [plex86] mini status report
>
>
> 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.)
Not a bad idea..., but not a great idea. For proof of this think out the
overhead necessary on a host filesystem to expand (in a DOS fs) or re-write
(in a uni* style fs like minix or ext2) the drive image file when you do
this. If you are not changing the size of the file then there is little
host overhead to cover hard disk access, since the file does not need to be
moved/expanded/rewritten each time that the file it written to.
> >
> >I would expect this feature to be of limited enhancement since
> >DOS/Windows certainly will write to many sectors on disk.
Again..., go back to the basics of how the fs works.., these are NOT things
that we want our framework to care about. Also, as an aside, DOS (& the
Win32API that runs on top of it) does not write hara-kiri onto the hard
disk--it is a quite orderly algorithm (not much unlike those for handling
arrays, maps, trees, heaps, and sets).
>
> 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.
As I said before.., there is logic to all hard drive accesses!!!!
>
> 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?
For this proposal think about the extra overhead necessary to make it work.
If you know much about hardware level disk access you soon realize that it
would be an unacceptable amount of time/clock cycles spent performing
ancillary tasks that would result from the use of this rather interesting
algorithm. It is possible that the guest image could be stored "compressed"
in this way, however; when it is NOT running--and only when it is not
running!!!
>
> 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.
Sounds a hell of a lot like a C++ vector to me........ Would work great for
swappable guest memory (which is going to raise overhead some anyway), but I
don't know about disk emulation--because the size of a sector (512B) is not
something that can be taken lightly from a memory standpoint. This has a
lot to do with the fact that whatever isn't written IMMEADIATELY TO DISK
needs to be cached somehow in this type of scheme. It is possible to do
this caching in a disk file..., but think about the overhead again.
>
> 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.
In short, NO!!!! Doing this would require us to do a hell of a lot of extra
work to build in a hell of a lot of incompatibility!!! Remember "KISS"
("Keep It Simple Stupid," not to say that you are ;^) )? The simplest
solution is often the best--fastest, smallest memory footprint, most robust
& fail proof. We want to emulate a disk...., not "drivespace.bin"!!! Also,
it should be mentioned that format information is not trivial, or disposable
by any means. The format information was thought out long and hard before
somebody decided that it was worth the storage space that it would take up.
Thus, DOS volumes have 2 copies of the FAT tables for a damned good reason &
the same with the way ext2 makes copies of the superblocks & inode bitmaps.
THIS IS NOT TRIVIAL DATA THAT CAN BE IGNORED!!!
>
> 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.
Think about the overhead!!!
>
> 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.
The idea of choice--through a plugin or otherwise is not a bad idea,
however; especially for this type of strategy that you describe (if it were
running on a damn big server!!).
>
> 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,
NP....., this is good fodder for my Data Structures class!!!!!
>
> Nik Borton
> Software engineer, Thermo Elemental (Winsford)
> mailto:[EMAIL PROTECTED]
> http://www.tjasolutions.com
>
> "The opinions expressed here are those ... blah blah, yakkity
> schmakkity ...
> "
>
