Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!unido!opal!tub!gmdtub!bigfoot.first.gmd.de!tmh
From: tmh@bigfoot.first.gmd.de
Newsgroups: comp.unix.sysv386
Subject: Re: How do I disable FFS?
Message-ID: <170@bigfoot.first.gmd.de>
Date: 19 Nov 90 18:37:14 GMT
References: <1110@bcs800.UUCP>
Sender: tmh@bigfoot.first.gmd.de
Lines: 47


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