Re: Beating a dead horse

[Greg Oster <oster%netbsd.org@localhost>]

On Thu, 26 Nov 2015 04:41:02 +0700
Robert Elz <kre%munnari.OZ.AU@localhost> wrote:

>     Date:        Wed, 25 Nov 2015 14:57:02 -0553.75
>     From:        "William A. Mahaffey III" <wam%hiwaay.net@localhost>
>     Message-ID:  <56561F54.5040207%hiwaay.net@localhost>
> 
> 
>   |   f: 1886414256  67110912       RAID                     # (Cyl.
> 66578*- | 1938020)
> 
> OK, 67110912 is a multiple of 2^11 (2048) which is just fine.
> The size is a multiple of 2^4 (16) so that's OK too.
> 
>   |           128  7545656543      1  GPT part - NetBSD FFSv1/FFSv2
> 
> The 128 is what I was expecting, from the dk0 wedgeinfo, and that's
> fine.  The size is weird, but I don't think should give a problen.
> Greg will be able to say what happens when there's a partial stripe
> left over at the end of a raidframe array.

RAIDframe truncates to the last full stripe.

> If you do ever decide to redo things, I'd make that size be a
> mulltiple of 2048 too (maybe a multiple of 2048 - 128).  Wasting a
> couple of thousand sectors (1 MB) won't hurt (and that's the max).
> 
> 
> But overall I think your basic layout is fine, and there's no need to
> adjust that.  The one thing that you need to do (if you really need
> better performance, rather than just think you should have it - that
> is, if you need it enough to re-init the filesystem) would be to
> change the ffs block size, or change the raidframe stripe size, so
> standard size block I/O turns into full size stripe I/O.
> 
> Doing that should improve performance.  Nothing else is likely to
> help.

The first thing I would do is test with these:

 time dd if=/dev/zero of=/home/testfile bs=64k count=32768
 time dd if=/dev/zero of=/home/testfile bs=10240k count=32768

so that at least you're sending 64K chunks to the disk... After that,
64K blocks on the filesystem are going to be next, and that might be
more effort than it's worth, depending on the results of the above
dd's... 

Later...

Greg Oster