vu2416@bingvaxu.cc.binghamton.edu (vu2416) (03/19/91)
There was a thread going for a while about writing a defragmenter for Commodore disks. I was seriously considering writing one (I've got code laying around that'll show the list of tracks and sectors in use by a particular file etc...) when I realized that the following process will work a lot faster: 1. Format a temporary disk 2. Copy the disk to defragment onto the temp disk 3. Format the defrag. disk 4. Use a file copier to copy all the files back onto the defrag. disk. DOS should write all the files in track / sector order. My best idea was to use the REU as the temporary disk. Maybe when I get my REU (it's in the mail) I'll look at the RAMDisk code to see if I can write a 'defragment' command. If anyone's interested. :) Comments would be appreciated. Gregg Riedel consp24@bingsuns.pod.binghamton.edu
nrossi@jarthur.Claremont.EDU (Nick Rossi) (03/19/91)
In article <1991Mar19.041534.27398@bingvaxu.cc.binghamton.edu> vu2416@bingvaxu.cc.binghamton.edu (vu2416) writes: > There was a thread going for a while about writing a defragmenter >for Commodore disks. I was seriously considering writing one (I've >got code laying around that'll show the list of tracks and sectors in >use by a particular file etc...) when I realized that the following >process will work a lot faster: >1. Format a temporary disk >2. Copy the disk to defragment onto the temp disk >3. Format the defrag. disk >4. Use a file copier to copy all the files back onto the defrag. >disk. >DOS should write all the files in track / sector order. My best idea >was to use the REU as the temporary disk. Maybe when I get my REU >(it's in the mail) I'll look at the RAMDisk code to see if I can write >a 'defragment' command. If anyone's interested. :) >Comments would be appreciated. CBM DOS seems to write files in order of every ten sectors. For example, the first file on a disk would start at track 17 sector 0, and then save to track 17 sector 10, t 17 s 1, t 17 s 11, t 17 s 2, etc. Copying files to a blank disk would produce this kind of ordering. I don't know if this makes for faster access or not. Maybe the physical organization of the disk works this way or something. This is what I wanted to know about. I normally just recopy files onto a blank disk when I am getting ready to release stuff on disk. >Gregg Riedel >consp24@bingsuns.pod.binghamton.edu Nick Rossi
cs4344af@evax.arl.utexas.edu (Fuzzy Fox) (03/20/91)
In article <11298@jarthur.Claremont.EDU> nrossi@jarthur.Claremont.EDU (Nick Rossi) writes: > >CBM DOS seems to write files in order of every ten sectors. For example, >the first file on a disk would start at track 17 sector 0, and then save >to track 17 sector 10, t 17 s 1, t 17 s 11, t 17 s 2, etc. Copying files >to a blank disk would produce this kind of ordering. I don't know if this >makes for faster access or not. Maybe the physical organization of the >disk works this way or something. The 'skipping' to every 10th sector or so on the disk is called interleaving, and it has a tremendous impact on the speed that the drive can access files on the disk. I have experimented quite a bit with this. Standard CBM DOS in the 1541 writes every file with an interleave of 10, such as in the order 0, 10, 1, 11, 2, 12, etc. This is because it takes time to process the data in a file between reading sectors, and while processing, the disk continues to spin in the drive. In many cases, after the drive finishes reading and processing one sector of a file, by the time it goes to look and see what sector is next, the disk has rotated about half-way around, which is about 10 sectors away. Think about it. If the first sector of a file were at 0, and the next were at 1, then after reading and processing sector 0, the drive wants to read sector 1. But sector 1 has already rotated away from the head, and the drive must wait until the disk spins all the way back around again before it can read the next sector. Essentially, the drive can only read one sector per revolution of the disk, and since the disk rotates five times per second, only 5 sectors per second can be processed. Now, if we use interleaving, the first sector 0 is read and processed, and by the time we look for the next sector, we only have to wait for the disk to spin around half-way before reading the next block. (This assumes we can process the sector quickly enough, and usually we can.) So, with an interleave of 10, we can read two sectors per revolution of the disk, meaning that 10 sectors per second can be processed. Twice the speed, and all we did is change the ordering of the sectors!! A 1571 uses a faster processor than a 1541, so it saves files with an interleave factor of 6. This means that it can read 3 sectors per revolution, or 15 per second. That's why a 1571 is faster in double-sided mode, but also why it is SLOWER in single-sided mode. The processor is slower in this 1541 mode, so it can't process disk sectors fast enough to read at an interleave of 6. If you want files to be read most efficiently on any drive, use an interleave of 10. DOS enhancements, such as JiffyDOS, Action Replay, and GEOS, change the interleave factor a bit more when they operate, so that the drive operates near their optimum speed. However, a 1581 drive has enough memory to buffer an entire track at a time, and so interleaving is useless on that drive. Super Snapshot V4 uses a novel scheme, in which it reads the sectors of a program, not in the normal order, but in the order which is most efficient, and the file is reassembled properly in memory after loading. This is probably the best scheme I've seen yet. Abnormal GCR formats such as Vorpal (Epyx) and Turbo*25 [these formats are actually identical except in directory structure] can be processed much faster than normal DOS formats, and they use an interleave factor of 2. This means that 10 sectors can be read per disk revolution, for a phenomenal transfer rate of 12K per second! It's a pity that this format didn't catch on more. If anyone is further interested in all of this techno-babble, there's always E-mail. :) -- David DeSimone, aka "Fuzzy Fox" on some networks. /!/! INET: an207@cleveland.freenet.edu / .. Q-Link: Fuzzy Fox / --* Quote: "Foxes are people too! And vice versa." / ---