Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 5 Oct 1999 21:49:09 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Andrzej Bialecki <abial@webgiro.com>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: Non-standard FFS parameters
Message-ID:  <199910060449.VAA81656@apollo.backplane.com>
References:   <Pine.BSF.4.05.9910052244450.11622-100000@freja.webgiro.com>

next in thread | previous in thread | raw e-mail | index | archive | help
:Hi,
:
:The system in question (3.3-stable) needs to use a large FS (ca. 40GB).
:The defaults for such filesystem are ridiculous, given that it will hold
:at most couple of hundred big data files. So, my question is:
:
:* should I change the cpg (default 16) to some bigger value?

    No, let newfs figure it out.

:* is it safe to run production system with non-standard block and fragment
:size (e.g. 32768 and 4096)?

    Mmmm.  I ran into problems in -current trying to use a block size of
    64K.  It should be relatively easy for me to track this down and fix
    it, but I don't know if there are other problems lying in wait.

test3:/root# ps axl | fgrep nbuf
    0 14265 14201   0  -2  0   620  536 nbufkv D+    p0    0:02.55 cpdup / /mnt


:* what maximum value can I use for -i (bytes per inode) parmeter? I
:aalready tried 16mln ...

    I wouldn't go that high.  Try 262144.  Here's an example:
    
    newfs -i 262144 -b 65536 -f 8192 /dev/rvn1c

test3:/root# newfs -i 262144 -f 8192 -b 65536 /dev/rvn1c
/dev/rvn1c:     83886080 sectors in 2560 cylinders of 1 tracks, 32768 sectors
        40960.0MB in 160 cyl groups (16 c/g, 256.00MB/g, 1024 i/g)


:* and finally, how th above choices affect the FS performance in my case?
:
:Thanks in advance for any insights!
:
:Andrzej Bialecki

    The higher the bytes per inode the fewer the inodes and the faster
    fsck will run if you have to recover the filesystem.  Too high a 
    bytes-per-inode will screw up the filesystem's ability to manage
    the cylinder groups, though.

    The higher the block size the fewer indirect blocks are required to 
    access a linear file, but as the block size increases the system's
    caching effectiveness will decrease.

    I would not use a block size greater then 64K, and I wouldn't specify
    a bytes-per-inode greater then 262144.

    There may be problems specifying larger block sizes, though nothing
    that we can't fix.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910060449.VAA81656>