Port-i386 archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: raw vs block speed difference?
On Fri, Aug 27, 2010 at 08:29:34AM -0600, Michael L. Hitch wrote:
> On Thu, 26 Aug 2010, Aaron J. Grier wrote:
>
> ># newfs -b 64k sd3d
> >/dev/rsd3d: 17501.8MB (35843664 sectors) block size 65536, fragment size
> >8192
> > using 6 cylinder groups of 2917.00MB, 46672 blks, 93184 inodes.
>
> I'm not sure if newfs updates the file system block sizes in the disk
> label anymore, so the label information may not reflect the actual
> sizes. In addition, I think the size used is actually the fragment
> size, which is 8K in this case.
On Fri, Aug 27, 2010 at 04:23:10AM -0400, jmitchel%bigjar.com@localhost wrote:
> If you mount the filesystem and do a dd to a file on the disk do you
> see the same throughput? I'm wondering if newfs has some overhead in
> it. In other words does:
>
> mount /dev/rsd3d /mnt
> dd if=/dev/zero of=/mnt/temp count=100000 bs=16384
>
> yield a different throughput result?
this was a bit eye-opening.
# newfs -b 16k sd0b
[...mount, cd...]
# dd if=/dev/zero of=bigfile count=130k bs=16k
133120+0 records in
133120+0 records out
2181038080 bytes transferred in 42.100 secs (51806130 bytes/sec)
# dd if=bigfile of=/dev/null bs=16k
133120+0 records in
133120+0 records out
2181038080 bytes transferred in 41.957 secs (51982698 bytes/sec)
this is close to the raw device speed. (64k blocks gives similar
numbers.)
On Fri, Aug 27, 2010 at 08:29:34AM -0600, Michael L. Hitch wrote:
> You can run iostat during the transfer and see what the actual read
> size of the disk is.
tty sd0 CPU
tin tout KB/t t/s MB/s us ni sy in id
[ writes ]
0 18 63.84 792 49.38 0 0 6 0 94
0 18 63.95 805 50.25 0 0 6 0 94
0 18 63.75 783 48.73 0 0 5 0 94
[ reads ]
0 18 63.85 822 51.24 0 0 5 0 95
0 18 63.89 821 51.19 0 0 5 0 95
0 18 63.87 820 51.17 0 0 5 0 95
looks like things are being amortized?
the moral of the story is that a dd of a block device is no indicator of
filesystem performance, so I apparently have nothing to be concerned
about.
back to RAIDframe tuning. ;)
--
Aaron J. Grier | "Not your ordinary poofy goof." |
agrier%poofygoof.com@localhost
Home |
Main Index |
Thread Index |
Old Index