tima@bcs800.UUCP (Tim Addington) (11/13/90)
I recently upgraded my system to a 650 Meg SCSI drive. My question is is there anyway to speed up the mounting and dismounting of the various filesystems. It is taking about 10 minutes now to bring up and shut down the system. Is this due to the Fast File System or the High Performance Disk Driver or what. I would like to disable this while I am setting up the system. The system is configured as follows: ISC 2.2 Micropolis 680 SCSI Drive Adaptec 1542A Controller 8 Meg RAM 386/25
tim@delluk.uucp (Tim Wright) (11/14/90)
In <1110@bcs800.UUCP> tima@bcs800.UUCP (Tim Addington) writes: >I recently upgraded my system to a 650 Meg SCSI drive. My question is >is there anyway to speed up the mounting and dismounting of the various >filesystems. It is taking about 10 minutes now to bring up and shut down >the system. Is this due to the Fast File System or the High Performance >Disk Driver or what. I would like to disable this while I am setting up the >system. Do you have everything on the root partition or do you have the drive partitioned more "normally". If you have one large partition, you will definitely see this. I know that in Dell UNIX (ISC derived), the slow mounting "problem" was fixed in version 1.1. Don't know if this helps ! Tim -- Tim Wright, Dell Computer Corp. (UK) | Email address Dell Computer Corp. (UK), Bracknell | Domain: tim@dell.co.uk Tel: +44-344-860456 | Uucp: ...!ukc!delluk!tim "What's the problem? You've got an IQ of six thousand, haven't you?"
itwaf@wafbox.UUCP (Bill Fulton) (11/15/90)
In <1110@bcs800.UUCP> tima@bcs800.UUCP (Tim Addington) writes: >I recently upgraded my system to a 650 Meg SCSI drive. My question is >is there anyway to speed up the mounting and dismounting of the various >filesystems. It is taking about 10 minutes now to bring up and shut down >the system. Is this due to the Fast File System or the High Performance >Disk Driver or what. I would like to disable this while I am setting up the >system. I asked the same question in this group several weeks ago, and got several very good responses, by mail. Many told me, quite politely, to RTFM. Connor Cahill (a great contributer to this group and many others, BTW) even gave me the page number for ISC. Here's a paraphrase of the answers I got: The FFS (Fast File System) gives a dramatic increase in file system performance. The main trade-offs seem to be: > Slow mounts and dismounts - Because the entire (?) free list is read into memory, and kept in memory until the dismount, at which time the entire free list is written back to the partition(s). I have 750Mb of disk space (2 disks), and it does take a very long time. > An arguably more fragile file system on crashes. (Not really much more fragile - but you get a *very* scary diagnostic from fsck when you bring the system back up. The doc warns you of this, and says that it's just a side- effect of the free list being out of sync). I have always found that fsck was able to recover very well. It is the free list load/unload that is taking all this time. My system (ISC) doc says the "solution" is to disable the FFS; by installing the "old style" 2K file system. I haven't tried it yet, but probably will do so on my home system, and leave the work system as is. Note that, on ISC, the default file system is FFS, and the 2K system is an optional driver. Here's another approach: I put the mount of the bigger disk (600Mb) in the background. The root and /usr partitions (150Mb disk) are mounted relatively quickly, and the /usr2 is dedicated to an application. The ISC system seems to be very good about handling any request to the /usr2 system as it is being mounted - all requests just freeze until the mount is complete, and then continue normally. Granted, this could confuse users, but it works quite well for maintenance work or emergency reboots. The implementation of this was a hack - I commented out the fstab entry for /usr2. A system which changes partitions with any frequency would not be easy to maintain. I recall a thread in this group about problems with the 2K file system. Is there still a problem, particularly with ISC 2.2? BTW - The mount/umount delay is suppossed to decrease as the disk become fuller (since the free list becomes smaller). I suppose you could attack the problem by keeping the disk artificially loaded with dummy files, and have a cron entry to delete the dummy files as the free space reaches a low-water mark. Funny - now we're worried about *too much* disk space! Thanks to all those who responded to my original post. waf
tmh@bigfoot.first.gmd.de (11/20/90)
In article <1110@bcs800.UUCP> Tim Addington writes: |> I recently upgraded my system to a 650 Meg SCSI drive. My question is |> is there anyway to speed up the mounting and dismounting of the various |> filesystems. It is taking about 10 minutes now to bring up and shut down |> the system. Is this due to the Fast File System or the High Performance |> Disk Driver or what. I would like to disable this while I am setting up the |> system. |> |> The system is configured as follows: |> |> ISC 2.2 |> Micropolis 680 SCSI Drive |> Adaptec 1542A Controller |> 8 Meg RAM |> 386/25 That's easy enough! The mounting/unmounting time of ISC's Fast File System is directly proportional to the free disk space available. The more you got, the longer it takes. This is because ISC reads the free block list off the disk upon mounting to create a bitmap of free disk space in main memory. Searches for free blocks are then satisfied from the bitmap rather than the disk, and this is one of the main reasons why the FFS is faster than the usual V7. At the same time the free list is cleared on the disk to guard against crashes. Since it's updated on the disk only upon unmounting it's safer to say that there are NO free blocks and have 'fsck' disprove that, than having a block in the free list on disk, while it was actually written on after the last mount and before the crash. Since rebuilding the free list seems about as expensive as simply loading and clearing it, ISC might as well never write it and have it's incore version reconstructed from the disk on mounting. So if mount/unmount times trouble you, I can exchange your 680MB disk for a 80MB drive (that (un)mounts *very* fast) completley free of charge! On the other hand you might just create a /usr/gobble directory with a couple of big files in it, artificially using up space. You'd have to remember to remove them, when the disk fills up with. Experience hath shown, that this problem goes away faster than you'd like--no disk is really ever big enough, if only because it takes so much time to throw all that junk away... Another possibility would be to return to original S51K file system. It's a lot slower generally (but then file system performance might or might not be important for your kind of work) but it surely (un)mounts faster. ---- Thomas M. Hoberg | UUCP: tmh@prosun.first.gmd.de or tmh%gmdtub@tub.UUCP c/o GMD Berlin | ...!unido!tub!gmdtub!tmh (Europe) or D-1000 Berlin 12 | ...!unido!tub!tmh Hardenbergplatz 2 | ...!pyramid!tub!tmh (World) Germany | BITNET: tmh%DB0TUI6.BITNET@DB0TUI11 or +49-30-254 99 160 | tmh@tub.BITNET