Date: Sat, 21 Aug 1999 20:32:23 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: Doug@gorean.org (Doug) Cc: phk@FreeBSD.org (Poul-Henning Kamp), cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/release/sysinstall install.c label.c options.csysinstall.h Message-ID: <199908220332.UAA31306@gndrsh.dnsmgr.net> In-Reply-To: <37BF4E89.D3CD53C2@gorean.org> from Doug at "Aug 21, 1999 06:12:41 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> Poul-Henning Kamp wrote:
> >
> > phk 1999/08/05 12:50:27 PDT
> >
> > Modified files:
> > release/sysinstall install.c label.c options.c sysinstall.h
> > Log:
> > Make the newfs parameters a global option.
> >
> > The default is still "-b 8192 -f 1024" but my experiments show that
> > "-b 16384 -f 4096 -c 100" is a more sensible value for modern
> > disksizes.
>
> I'm curious, why is making the block size bigger a better thing? I would
> think that with disks getting bigger all the time we'd want to decrease the
> block size to avoid the wastage of unused partial blocks being multiplied
> over very large disks. This is a legitimate request for info, I'm not an fs
> expert by any means.
Average file sizes are getting larger for one, so now you end up wasting
a larger portion of the disk used for inode and other meta data with the
8K block size. Also note that the fragment sized did not have to increase
to 4K, it could go to 2K and still meet the maximal allowed block/frag
ratio of 8, I would rather see that unless phk has some driving reason
we need to decrease this ratio, as that would cause a significant amount
of wasted space for the bazzilion little files things like /usr/ports
has in it. [I think I found out why he did this as well, see my question
to Poul in the next paragraph.]
Probably the major reason Poul increased the block size though, was you
have to be able to fit certain tables of a cylinder group into 1 block,
or newfs complains and truncates the cgrp size. Large numbers of cgrp's
are not really needed, and don't buy you any more performance. With the
-c 100 above they would be about 400MB in size, or 10 of them on a 4G
drive (assuming -u is 4096 still), a 1/10th seek is about the same as
a 1/60th seek as far as how long the drive takes to get it done, so
you don't loose any performance. Actually it looks like you have to
fit certain things into a fragment as well, wasn't aware of that, care
to fill me in on what I have forgotten about ufs layouts Poul?
I have some concerns about the resulting number of inodes that these
changes cause:
myname.my.domain:{root}{121}# newfs -b 16384 -f 4096 -u 4096 -c 128 /dev/rda1h
myname.my.domain:{root}{122}# mount /dev/da1h /mnt
myname.my.domain:{root}{123}# df -ik /mnt
Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on
/dev/da1h 3401228 4 3129128 0% 1 213245 0% /mnt
myname.my.domain:{root}{124}# newfs -b 8192 -f 1024 -u 4096 /dev/rda1h
myname.my.domain:{root}{122}# mount /dev/da1h /mnt
myname.my.domain:{root}{123}# df -ik /mnt
/dev/da1h 3322494 1 3056694 0% 1 833277 0% /mnt
I'm kinda a power of 2's person, and I am about to do a nuke and pave
a few of the systems within our AS to the builds of 3.2-stable I just
finished, and I am going to go put into production the following (bare
problems found in the next 2 hours in building the master distribution set:)
newfs -b 16384 -f 2048 -u 2048 -c 128 -i 4096 /dev/rda1h
That gives me 128MB cylinder groups, a nice small fragment for all them
itty bitty files, a big fat block for the larger files, and enough inodes
I shouldn't run out except if I put a news spool or web cache on it.
--
Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908220332.UAA31306>