Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!wafbox!itwaf From: itwaf@wafbox.UUCP (Bill Fulton) Newsgroups: comp.unix.sysv386 Subject: Re: How do I disable FFS? Message-ID: <136@wafbox.UUCP> Date: 15 Nov 90 04:45:11 GMT References: <1110@bcs800.UUCP> Reply-To: itwaf@wafbox.UUCP (Bill Fulton) Organization: Home Lines: 53 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