In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes >[EMAIL PROTECTED] wrote: > >> Every time I use it I get the reassuring answer that the hard drive does >> not need a Defrag. > >I think it has to be *really really* bad before you get told to defrag. >I recently did lots of deletions and a general housekeep here at work >and decided to defrag - it say that the disc was (somnething like) 96% >fragmented but I didn't need to defrag. Go figure. > >I ignored the advice and set a defrag in motion overnight. Next >morning, it was still running :o)
Weird ... :-) ..... I have usually found that the Defrag starts to kick in when the hard drive 5% to 10% fragmented. However, as you say if you have a very large hard drive installed then be prepared for a long wait ... >> As far as Windows is concerned it is just one large file, so it cannot >> itself be defragmented - which is what happens to the hard drive surface >> area having gaps between areas of occupied data and areas not occupied >> by data. >I beg to differ (if I may). It makes no difference how big the file is >(unless it is a single extent), it can be fragmented. A two extent file >can have one extend in location A and another in location >A+lots_of_displacement. That file is, technically, 50% fragmented and >can be defragged. > > >> The Defrag with DOS/Windows packs the data together, removing the >> fragments that got separated to be a whole continuous area of data. >This is correct. > > >> Internally I don't know how the QXL.WIN holds its directions to >> information. Yet it will not be affected by defragmenting. >It can be. If the QXL.WIN file is spread of lots and lots of diosc >area, in multiple fragments, then whenever the internal pointer says >'go here' that has to be transl;ated to a disc address physically on >the drive platter(s). If you need to read lots of chuncks at 'random' >locations then each read incurrs a rotational delay plus seek time plus >latency period - which increase access times. > >If the chuncks of QXL.WIN you want are contiguous (or interleaved >'continuously') then there is a single 'mul;ti-block' read rather than >lots of small reads. This incurs minimal rotational delay and latency >or seek time and speeds up the read operation. > > >> I guess someone can look all this up in the manuals ..... >Someone had to learn this stuff for an exam some time back. Assuming >the Oraganic RAM is still sort of working, the above should still be >true. I don't think disc technology has progressed very far (other than >in hardware) in the intervening years, however, I am always open to >corrections - as those of you who have read my series on Assembly >Language Programming will attest. :o) An interesting topic. On my other system RISC OS there is no such thing as a Defrag option ... so I assumed that with that OS it just never occurs. I recently, and finally, managed to fill a 500Mb hard drive ( yes small by PC standards ... like the QL world ) and it just politely told me the drive was full. I then just moved some data to a removable drive and carried on as usual. He drives are SCSI 1. -- Malcolm Cadman _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
