Chris_F_Chiesa@cup.portal.com (04/12/91)
Hello All. Had to edit the mountlist on the floppy-I-boot-from, last night, and now the disk seems to "grind" back and forth a lot more than it used to, and take longer to boot. (Well, it did last night when I first DID this editing; this morning it seemed okay. Is my mind playing tricks on me?) I don't really KNOW for sure why the disk might grind more after I edited the mountlist file, but it's extremely full (no room even for a backup copy of the mountlist) and I remember reading somewhere a few years ago that the disk could get "fragmented" causing the head to have to jump all over the disk to pick up pieces of the file, and I am hoping THAT is the plain explanation. If you know/think otherwise, please let me know. If I am correct, then I have two questions. 1) I remember also reading (on this Net) a few years ago, about a PD "boot-floopy optimizer" utility that you could run, which would reorganize the boot disk to eliminate/minimize the back-and-forth "grinding" effect at boottime. Does anyone else know of this utility, and can you point me at a copy of it? 2) If there is no such animal as (1), can anyone suggest a workaround for (cringe, cringe) HAND reorganization of the disk? Or other so- lutions to the problem? (Example: on the old Atari 800 you could recover certain disk-space wastage by copying all the files, one at a time, to another disk. Is there an equivalent strategy here?) Please e-mail as well as posting, as I have a devil of a time even GETTING AT these groups, much less reading them with any regularity. Thanks! Chris Chiesa Chris_F_Chiesa@cup.portal.com "Trying to become a knowledgeable Amigan!"
jap@convex.cl.msu.edu (Joe Porkka) (04/13/91)
Chris_F_Chiesa@cup.portal.com writes: >Hello All. > Had to edit the mountlist on the floppy-I-boot-from, last night, and >now the disk seems to "grind" back and forth a lot more than it used to, >and take longer to boot. (Well, it did last night when I first DID this >editing; this morning it seemed okay. Is my mind playing tricks on me?) Your mind aint playing tricks - its our computer. What you probly did was to "Save" the file, the reboot immediatly, right? If so, then you probly forgot to wait 2-secs after the drive light goes out before rebooting - therefor the computer did not get a chance to clean up the disk (write out the sector bitmap), and so the next time the OS saw the disk (right after reboot) it had to validate the disk - as well as booting from it, causeing lots of disk seeks and a SLOW reboot. Try rebooting again, and it should be quick like your second try. >years ago that the disk could get "fragmented" causing the head to have Yes, disks can get fragmented. Its no likely that editing one file would cause a noticable difference. It could cause a slight difference if you made the file significantly larger. > 2) If there is no such animal as (1), can anyone suggest a workaround > for (cringe, cringe) HAND reorganization of the disk? Or other so- > lutions to the problem? (Example: on the old Atari 800 you could > recover certain disk-space wastage by copying all the files, one at > a time, to another disk. Is there an equivalent strategy here?) Yes this too will work, but you can do something like: copy df0: to df1: all clone to do the single-file at a time copy, but with nly one command. Assumeing that you have two floppy drives (or lots of memory, or a hard disk)
maxc1553@ucselx.sdsu.edu (InnerTangent - human1) (04/15/91)
Having struggling with diskettes for daily for the last 1.5 years, I learned that if your disk have 0 bytes left, the amiga drive will always struggle with it for a while until it accept the disk. It doesn't get validated or something. So, all I can say is to delete one file.. (maybe a useless .info) or try compressing some not-so-often used commands with powerpacker/imploder. Then, after there are more spaces left on your disk, check your mountlist, make sure it got saved completely. Make all the changes, then optimize your boot disk with any good optimizers.. Bad is ok, and there are several PD/Shareware disk optimizers around. (check ftp-sites, local BBS') If you are completely floopy disk based Amiga, Try squeeze as much stuffs onto your floopy as possible. Newest PowerPacker-Professional(commercial) will let you compress most executable files. Turbo Imploder will even compress fonts and libraries, keymaps, printer-drivers too. Saving even more space on your bootdisk. allowing more programs to be on the same floppy. These above are my solutions before I got my HD recently. I'm happy. -- [unify] ************************************************************************* * All those moments will be lost in time, like tears in the rain. + *-----------------------------------------------------------------------+
steve@wildcat.UUCP (Steve Holland) (04/16/91)
>In article <41207@cup.portal.com> Chris_F_Chiesa@cup.portal.com writes: >Hello All. > > Had to edit the mountlist on the floppy-I-boot-from, last night, and >now the disk seems to "grind" back and forth a lot more than it used to, >and take longer to boot. (Well, it did last night when I first DID this >editing; this morning it seemed okay. Is my mind playing tricks on me?) > > I don't really KNOW for sure why the disk might grind more after I >edited the mountlist file, but it's extremely full (no room even for a >backup copy of the mountlist) and I remember reading somewhere a few >years ago that the disk could get "fragmented" causing the head to have >to jump all over the disk to pick up pieces of the file, and I am hoping >THAT is the plain explanation. > > If you know/think otherwise, please let me know. If I am correct, >then I have two questions. > > 1) I remember also reading (on this Net) a few years ago, about a PD > "boot-floopy optimizer" utility that you could run, which would > reorganize the boot disk to eliminate/minimize the back-and-forth > "grinding" effect at boottime. Does anyone else know of this utility, > and can you point me at a copy of it? > > 2) If there is no such animal as (1), can anyone suggest a workaround > for (cringe, cringe) HAND reorganization of the disk? Or other so- > lutions to the problem? (Example: on the old Atari 800 you could > recover certain disk-space wastage by copying all the files, one at > a time, to another disk. Is there an equivalent strategy here?) This happens all the time when you have REALLY full disks. What seems to happen is that when AmigaDos fills up the disk, to get a TINY amount of extra space, it removes some disk-validation stuff normally run whenever you put the disk into the drive. When this happens, it causes a big increase in the time taken to validate a disk and also it causes grinding when you boot. If it is not your boot disk you will also have to swap in your boot disk WHENEVER you insert it into your drive. To solve this problem, remove one of the more useless files and type: Install df0: If your disk is not a boot disk, type: Install df0: NOBOOT Do this to any disk which (according to info) is 100% full. >Please e-mail as well as posting, as I have a devil of a time even GETTING >AT these groups, much less reading them with any regularity. Thanks! > > Chris Chiesa > Chris_F_Chiesa@cup.portal.com > "Trying to become a knowledgeable Amigan!" -- ----------->Steve Holland<----------- Internet: wildcat!steve@alphalpha.com| "I never let my schooling get in the USENET: ...!alphalpha!wildcat!steve | way of my education" -Mark Twain
jms@tardis.Tymnet.COM (Joe Smith) (04/17/91)
In article <41207@cup.portal.com> Chris_F_Chiesa@cup.portal.com writes: > Had to edit the mountlist on the floppy-I-boot-from, last night, and >now the disk seems to "grind" back and forth a lot more than it used to, >and take longer to boot. (It's extremely full.) When a floppy is completely full, AmigaDOS does not write out the bitmap. The allows you to use the very last available block for your data. The disadvantage is that the bitmap (which tells AmigaDOS which blocks are in use and which ones are available) does not get stored. When AmigaDOS sees a floppy in this state, it knows that it has to rebuild the in-memory copy of the bitmap by locating every single file on the disk. This is the delay you see. The fix is easy. Delete an unneeded file so that the floppy has at least 1 block free. -- Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-C51 | BIX: smithjoe | CA license plate: "POPJ P," (PDP-10) San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga 3000 speaks for me."