Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!daver!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.sys.amiga Subject: Re: Slow workbench disk problem Message-ID: <1990Dec23.142630.11007@zorch.SF-Bay.ORG> Date: 23 Dec 90 14:26:30 GMT References: <1749@winnie.fit.edu> Organization: SF-Bay Public-Access Unix Lines: 36 mark@zach.fit.edu ( Mark R. Craig) writes: > [the usual sad story of filling up a floppy and having it take forever to > "ready" every time it's inserted.] This may not be your problem, but the odds are good that you _exactly_ filled up the disk. Amy likes to have one block left to write some "validating" data about the disk (a bitstring with a "1" set for every sector in use, I think, but it doesn't matter). When you modify the disk, this information gets updated; that's what that little "late hit" is after you finish writing a file to the floppy; a short wait to make sure you're done, then a copy of the updated information from ram to floppy. If you exactly fill up the disk, Amy doesn't die, but you've overwritten the old, invalid block of information, and left nowhere to write the new one. So, when you put the disk back in, Ami has to look at the whole disk to rebuild this information, rather than just reading it in from the disk. Worse (I'm guessing here), I think it doesn't just read 80 tracks one after the other, which would be fairly fast and would sound different, but instead walks the entire directory tree to see which blocks are actually linked in; this is the worst case way to access an AmigaOS floppy, which is why it is so slow and noisy. The _reason_ it can't just read 80 tracks in a row is that old sectors for deleted files aren't zeroed out in AmigaOS, so looked at one by one they'd still seem to be in use; this is why DiskSalve can sometimes recover a deleted file. Short solution: take something off your workbench disk to free up at least one block. Kent, the man from xanth.