: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
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
