Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!aplcen!haven!adm!news
From: justice@dao.nrc.ca (Gerald Justice)
Newsgroups: comp.unix.wizards
Subject: How to optimize BSD (SunOS 4) file system (esp. for Big partition)?
Message-ID: <22401@adm.BRL.MIL>
Date: 9 Feb 90 13:45:57 GMT
Sender: news@adm.BRL.MIL
Lines: 53

I am looking for some advice on optimizing the file systems on a Sun 4/280
NFS and boot server running SunOS 4.0.1 (soon 4.0.3) used in a scientific
data analysis environment.  The clients are 3/60's and 4/60's, all diskless.

I have:
I)   Read and re-read the mkfs(8), newfs(8), tunefs(8), and fs(5) man pages.
II)  Read chapter 7 (the file system chapter) of _The_Design_and_Implemen-
     tation_of_the_4.3_BSD_Operating_System_ by Leffler, McKusick, Karels,
     and Quarterman.  (Very enlightening but didn't answer my questions.)
III) Looked for but failed to find anything useful in the Sun "Network and
     Administration Manual" even though all the above man pages refer there.

Specifically, I would very much appreciate:
I)  A copy of _A_Fast_File_System_for_UNIX_, McKusick, Joy, Leffler.  Can I
    ftp it from somewhere? (This is also referenced in the Sun man pages.)
II) Advice on the effects of changing the following parameters:
   A) number of cylinders per group
     1) If one has a very large file system (order 700Mb) intended for
        storing primarily large files (.25 to 2 Mb) although small files
        will also occur in this fs, is there any point to increasing this
        parameter?
     2) If one has a partition for diskless client swap space (say 8 * 32 Mb)
	is there any advantage to increasing this parameter?
     3) If one has a very small partition, say 24 cylinders is there any
	benefit in setting this parameter to 12 to have two equal
	sized groups rather than two different sized (16 and 8) groups?
   B) maximum blocks per group
     1) as in A1) above, should this parameter be increased?  How much
	is safe? Note that efficiency of access for large files is more
	important than for small files.
     2) as in A2) above, is there any benefit to increasing this parameter?
   C) minimum free space
     1) as in A1) above, can less than 10% be "gotten" away with?  10% of
	700Mb is a lot of "elbow" room, and seems inappropriate.  But
	read/write efficiency is the primary objective for this fs so I
	don't want to sacrifice that to gain some more space.
	(But I do so want more space!)
     2) as in A2) above, is this really a "static" partition (like /usr)
	and can I safely set free space to 0?
   D) bytes per inode
     1) I plan to double this parameter for those fs's where average
	file size is fairly large and where similar partitions currently
	show inode utilization below 30% but space utilization near 90%.
     2) as in A2) above, is there any reason not to set the bytes per inode
	to the actual swap file size? Should I really create just 8 inodes?
	(Actually I would create 16 just in case, I suspect it is impossible
	to get less than some minimum like blksize/inodes-per-blks?)
   E) anything else that I can usefully adjust?

Thank you in advance.
Email responses will be summarized if there is sufficient interest.

justice@dao.nrc.ca BITNET:justice@nrcdao DAO Victoria, BC CANADA (604) 388-0055