Message-Id:	<m0wLGUU-000FjyC@hn.planet.gen.nz>
Date:	Sun, 27 Apr 97 11:02 NZST
Mime-Version:	1.0
To:	alaric AT abwillms DOT demon DOT co DOT uk
From:	Lorier <lorier AT ihug DOT co DOT nz>
Subject:	Re: Usage of directory entries
Cc:	pierre AT tycho DOT com, "Alaric B. Williams" <alaric AT abwillms DOT demon DOT co DOT uk>,
	Matthias DOT Paul AT post DOT rwth-aachen DOT de, opendos-developer AT delorie DOT com

>> >You mean /more easily done/. 
> 
>> Better: You don't have to "lock" files, you don't have race conditions and
>> hundres of other problems... There is far more that can go wrong if your
>> defragging AND allowing write access... 
>
>One possible solution is to defrag by rebuilding a copy of the file in a linear
>region somewhere, then switching from the old copy to the new one. While a file
>is being shifted, block read requests come from the old version, and 
>block write requests go to the new version, leaving a note to the copier not
>to copy the old version of that block from the original contorted file!

So, if for example your defragging a large database, its a gig or so in
size... It takes about 5 minutes to finish.... Someone adds $10 to a record
somewhere, rereads the record to see if it went in and sees it didn't...
oops. :)

Secondly that would require two gig of *CONTIGOUS* HDD space to defragment :)

>The background defrag need not be a perfect defragger. If we can just show that
>it will defragment most files without screwing anything up, then we can leave
>it chuntering away. A full scale bring-the-system-down defrag tool will only
>then be needed if empirical evidence shows that the background one isn't good
>enough!

Umm... If your background defragger screws up even ONE file consistantly
then people will abuse opendos for being unstable.  Remember Dos 6.2 with
Dblspace and smartdrv?  The delayed writeback on SmartDrive ment that people
that turned off there computers as soon as they saw the dos prompt ended up
not quite writting everything to disk... And DoubleSpace compounded the
problem by requiring all data to be flushed or it got into a very
inconsistant state. We don't want to go there :)

Also a defragger requires a lot of memory, CPU and disk access, three things
that machines that can't run win95 (one of our major targets) don't have
either :)

>> Adding up a CRC of something that
>> changes 1/2 way through is going to make things go BANG I think :)
>
>Now, how would that arise????

Don't ask... I'm *SURE* we'll find at least ONE way to do it :)
 
>> > Better for users if it happens invisibly.
> 
>> Umm... Semi-invisibly :)  Give the "power users" power to do what they
NEED. :)
>
>Yes, I'd agree with that. Invisible in general use, but /findable/ if you wanna
>see it!

"I'm your anti-virus program that is SURE that your autoexec.bat has a
bootsector virus, and I'm going to hide where you can't find me, so there :P"

- Raw text -