How do I disable FFS?

Bill Fulton itwaf at wafbox.UUCP
Thu Nov 15 15:45:11 AEST 1990


In <1110 at bcs800.UUCP> tima at 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



More information about the Comp.unix.sysv386 mailing list