[ On Sunday, March 24, 2002 at 10:12:01 (+0100), Wojciech Puchar wrote: ]
> Subject: Re: 160GB IDE Drives under NetBSD?
>
> > On the other hand 160MB of unused sectors on a 160GB FS is a very tiny
> > fraction of the available space -- hardly what I'd call "wastage" under
> > any circumstances!  :-)
> 
> but does this change make sense for me? will it speed up thinks noticably?

It might -- though I think it really will depend on how the disk itself
functions.  If a read of 16kB will always be satisfied with at most one
seek then that's probably a better size than 8kB, depending on of course
how many <8kB files you have, how your files are normally accessed, and
vs. the average size of reads in larger files (esp. those randomly
and frequently accessed).

pkgsrc/benchmarks/postmark is a good disk/FS benchmark if you can figure
out how to make it mimic your real usage patterns.....  :-)

All of my "large" filesystems are made up of multiple spindles (either
with CCD striping, RAIDframe RAID-5 striping, or hardware RAID-5
striping), so in those cases a larger block size will normally be read
with one low-level operation anyway, even if it has to be spread across
multiple physical devices -- they all happen in parallel.


> mine 13GB squid cache has 14kB average. but i set max file size to 64MB.

Though that's a smaller cache, I think my max file size is similar (or
maybe it's only 32MB) so the distribution of sizes in our caches should
be similar (esp. given the average is so close), though I suppose it may
depend on the user base somewhat.

> some times having larger blocks may actually save space as extra block
> for indirect blocks may not be needed.
> 
> how many direct blocks are per inode on FFS?
> i think it's 12 but i'm not sure

Yes, I think that's right:

/usr/include/ufs/ufs/dinode.h:
#define	NDADDR	12			/* Direct addresses in inode. */

> if 12 - up to 16*12=192kB file will fit. with 8kB it will be 96.
> 
> as 99% of squid files are <96kB i think 8K blocks are better here.

Ah, but what percentage of files are under 16kB, or even under 32kB, but
over 8kB?

I.e. how much are a few very large files skewing the average up?

If a majority of the files are under 16kB but over 8kB then 16kB blocks
are closer to the ideal size.

Unless you have gigabit interfaces and enough clients requesting the
same very large objects simultaneously that they are together faster
than your disks, you don't really care too much about the speed of
accessing large objects (i.e. those with indirect blocks).  You care
only about making the most commonly accessed objects fast -- there are
more of them and more accesses of them, typically.

Also remember that squid objects are generally sequentially accessed, so
going through indirect blocks doesn't cause any major and regular delay
(there'll probably be no delay at all from the client's perspective).

(not that a well sized squid is ever disk bound...   :-)

> so you think changing blocksize to 16kB make sense for me?

If the majority of your small files are bigger than 8kB, probably...   :-)

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>