Mail Archives: opendos/1997/04/27/18:28:33
On 27 Apr 97 at 11:02, Lorier wrote:
> >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. :)
Sorry, I should have said: the notes to the copier also redirect read
requests to the new block!
> Secondly that would require two gig of *CONTIGOUS* HDD space to defragment :)
Well, the large database file is a bad example.
> >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.
I didn't mean it like that - it will not defrag files it can't defrag without
screwing up! What I meant was that it may well not defragment everything
perfectly. It just does the best that can be done with a guarantee of
success. So the huge database file would probably be left well alone, unless
you had a huge HDD to copy it on!
> 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 :)
No, certainly not!
> 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 :)
That's why it goes on low priority... perhaps doesn't run at all until
after a certain time delay of no disk activity or low CPU load or something.
> >> 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 :)
Ah - I see!
ABW
--
Alaric B. Williams (alaric AT abwillms DOT demon DOT co DOT uk)
---<## OpenDOS FAQ ##>---
Plain HTML: http://www.delorie.com/opendos/faq/
http://www.deltasoft.com/faq.html
Fancy HTML: http://www.deltasoft.com/faq0000.html
- Raw text -