Comments: Authenticated sender is From: "Alaric B. Williams" To: Lorier Date: Sun, 27 Apr 1997 21:59:28 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Usage of directory entries Reply-to: alaric AT abwillms DOT demon DOT co DOT uk CC: pierre AT tycho DOT com, "Alaric B. Williams" , Matthias DOT Paul AT post DOT rwth-aachen DOT de, opendos-developer AT delorie DOT com In-reply-to: Message-ID: <862174546.067638.0@abwillms.demon.co.uk> Precedence: bulk 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