Re: Non-standard FFS parameters
On Tue, 23 Nov 1999, Joe Greco wrote: On Fri, 8 Oct 1999, Matthew Dillon wrote: : : Adjusting the bytes-per-inode (-i) specification in newfs should not : pose a problem. : :IOW now you say it's ok to use very high values of -i... ;-) : :Andrzej Bialecki No, I didn't say that. My recommended maximum is still 262144. Fsck should be reasonably fast with that number and the filesystem should still be able to maintain reasonable efficiency. Ok, I can live with that, I guess. Thanks a lot for your help! What's the recommended way to reduce the number of cylinder groups a bit? ...except manually changing the calculations in newfs/mkfs.c ? What values are reasonable for large filesystems? 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
Re: Non-standard FFS parameters
On Fri, 8 Oct 1999, Matthew Dillon wrote: : : Adjusting the bytes-per-inode (-i) specification in newfs should not : pose a problem. : :IOW now you say it's ok to use very high values of -i... ;-) : :Andrzej Bialecki No, I didn't say that. My recommended maximum is still 262144. Fsck should be reasonably fast with that number and the filesystem should still be able to maintain reasonable efficiency. Ok, I can live with that, I guess. Thanks a lot for your help! What's the recommended way to reduce the number of cylinder groups a bit? -c's maximum limit is affected by combinations of -b and -i, possibly some others. PHK was talking about new, more sensible values for filesystem parameters, but I don't know what happened. I just think it's a bit silly to go generating hundreds of cg's for a 34GB unit... and this _with_ the max -c setting of 26 (for this fs). /dev/vinum/rn8: 63700992 sectors in 15552 cylinders of 1 tracks, 4096 sectors 31104.0MB in 599 cyl groups (26 c/g, 52.00MB/g, 256 i/g) super-block backups (for fsck -b #) at: 32, 106528, 213024, 319520, 426016, 532512, 639008, 745504, 852000, 958496, ... Joe --- Joe Greco - Systems Administrator [EMAIL PROTECTED] Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Non-standard FFS parameters
:What's the recommended way to reduce the number of cylinder groups a bit? :-c's maximum limit is affected by combinations of -b and -i, possibly some :others. PHK was talking about new, more sensible values for filesystem :parameters, but I don't know what happened. I just think it's a bit silly :to go generating hundreds of cg's for a 34GB unit... and this _with_ the :max -c setting of 26 (for this fs). : :/dev/vinum/rn8: 63700992 sectors in 15552 cylinders of 1 tracks, 4096 sectors :31104.0MB in 599 cyl groups (26 c/g, 52.00MB/g, 256 i/g) :super-block backups (for fsck -b #) at: : 32, 106528, 213024, 319520, 426016, 532512, 639008, 745504, 852000, 958496, : :... Joe : :--- :Joe Greco - Systems Administrator[EMAIL PROTECTED] Well, -i doesn't effect c/g any where near as much as -b does. Try bumping the block size up to 16K and use '-c 999' and see what newfs tells you the max c/g is. -b 16384 -f 2048 -c 999. On my test it let me do 89 c/g. As we already know, non-standard block sizes will create problems under stable and may create them under current. I believe I have fixed the bugs under current (in getnewbuf()) but since no comprehensive testing has been done you still have a lockup risk. Work on the VM system mainly by Luoqi a few months ago fixed the buffer corruption bugs, so only lockup bugs should be left. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Non-standard FFS parameters
: : Adjusting the bytes-per-inode (-i) specification in newfs should not : pose a problem. : :IOW now you say it's ok to use very high values of -i... ;-) : :Andrzej Bialecki No, I didn't say that. My recommended maximum is still 262144. Fsck should be reasonably fast with that number and the filesystem should still be able to maintain reasonable efficiency. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Non-standard FFS parameters
On Wed, 6 Oct 1999, Matthew Dillon wrote: : 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) Running bonnie on the filesystem with these parameters results in unkillable process sitting in getblk (it's the first phase of bonnie test when they use putc() to create the file). It just sits there and doesn't consume CPU. The OS is 3.3-R. 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
Re: Non-standard FFS parameters
On Thu, 7 Oct 1999, Matthew Dillon wrote: : :Running bonnie on the filesystem with these parameters results in :unkillable process sitting in getblk (it's the first phase of bonnie test :when they use putc() to create the file). It just sits there and doesn't :consume CPU. The OS is 3.3-R. : :Andrzej Bialecki Hmmm. It's quite possible, 3.x's getnewbuf() code is pretty nasty. I have a solution under test for 4.x (current). There simply may not be anything that can be done for 3.x short of porting current's getnewbuf() code over, and doing so has been deemed too risky by DG due to all the collateral porting that would also have to be done. I agree with that assessment, plus it's a huge amount of work that I don't have time to do at this late date. Try using a smaller block size, like 16K. If that doesn't work then just stick with 8K I guess. The kernel's clustering code should still make it reasonably efficient. Yeah, I guess that's the only way to do it on 3.x... But how can I speed up fsck then, since newfs will create millions of inodes I don't need which will cause fsck to run for ages... 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
Re: Non-standard FFS parameters
: : Try using a smaller block size, like 16K. If that doesn't work then just : stick with 8K I guess. The kernel's clustering code should still make it : reasonably efficient. : :Yeah, I guess that's the only way to do it on 3.x... But how can I speed :up fsck then, since newfs will create millions of inodes I don't need :which will cause fsck to run for ages... : :Andrzej Bialecki The problem should only be effected by the blocksize (-b) specification. Adjusting the bytes-per-inode (-i) specification in newfs should not pose a problem. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Non-standard FFS parameters
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
Non-standard FFS parameters
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? * is it safe to run production system with non-standard block and fragment size (e.g. 32768 and 4096)? * what maximum value can I use for -i (bytes per inode) parmeter? I aalready tried 16mln ... * and finally, how th above choices affect the FS performance in my case? Thanks in advance for any insights! 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
Re: Non-standard FFS parameters
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? * is it safe to run production system with non-standard block and fragment size (e.g. 32768 and 4096)? * what maximum value can I use for -i (bytes per inode) parmeter? I aalready tried 16mln ... * and finally, how th above choices affect the FS performance in my case? One thing that bit me before (from the newfs man page) BUGS The boot code of FreeBSD assumes that the file system that carries the kernel has blocks of 8 kilobytes and fragments of 1 kilobyte. You will not be able to boot from a file system that uses another size. Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Non-standard FFS parameters
: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+p00: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
