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... ;-)
> > > :
>
: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 sill
> 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
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 maxi
:>
:> 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 wit
On Thu, 7 Oct 1999, Matthew Dillon wrote:
> :>
> :> 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
:>
:> 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
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
:
: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 possi
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
:> :* 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..
Because you don't gain anything by going higher. Once you get o
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 eat
: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 newf
>
> 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
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 prod
15 matches
Mail list logo