On Tue, 5 Oct 1999, Matthew Dillon wrote:
> 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.
IOW it may appear to run while eating your FS away.... No,thanks :-/
> :* 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:
Why? I only need a couple o hundred inodes on this fs..
>
> 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)
Well, yes, but you used non-standar blocksize which you yourself don't
recommend. With standard 8192/1024 this command creates millions of
inodes which I don't need - what's worse, they cause fsck to run for
hours instead of seconds.
>
> :* 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.
Why? I thought this parameter describes (indirectly) only the total number
of inodes in the FS, which is otherwise set proportionally to FS size,
assuming it will be filled with very small files (2048B IIRC).
I suspect it might have something to do with the placement policy (which
CG to use to put additional blocks belonging to the file), but I don't see
any immediate connection...
>
> 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.
What kind of problems? Will it simply not work, or will it corrupt the
FS?
Thanks a lot for these comments!
Andrzej Bialecki
// <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com)
// -------------------------------------------------------------------
// ------ FreeBSD: The Power to Serve. http://www.freebsd.org --------
// --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ----
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
