Solaris

The "zpool iostat" command shows some zpool statistics:

foo@bar> zpool iostat
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
ei01 123G 109G 1 1 19.7K 18.5K
ei02 46.8G 112G 2 0 335K 92.8K
---------- ----- ----- ----- ----- ----- -----

The meaning of these figures is not really documented in the man page, but easy to deduce: It is the average number of read and write requests per second and the average amount of data read and written per second, counted from boot (or, to be more correct, zpool import) time.

With an additional -v parameter, we get the same information not only on pool level, but also on device level:

foo@bar> zpool iostat -v
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
ei01 123G 109G 1 1 19.7K 18.5K
mirror 123G 109G 1 1 19.7K 18.5K
c0d1 - - 0 0 13.9K 18.5K
c1d0 - - 0 0 13.6K 18.5K
---------- ----- ----- ----- ----- ----- -----
ei02 46.8G 112G 2 0 335K 92.8K
c0d0s7 46.8G 112G 2 0 335K 92.8K
---------- ----- ----- ----- ----- ----- -----

If you want the raw data for this, then you have to help yourself. See the zpstat.c I have just written. Compile instructions inside (very simple!). Usage: zpstat <pool1> [<pool2> ... <pooln>]. For each given pool, it will iterate through the in-core vdev tree structure and for each vdev it will try to extract statistics information. Output looks like this:

ei02
type: 'root'
id: 0
vdev_stats.vs_timestamp: 693868 seconds
vdev_stats.vs_ops[ZIO_TYPE_NULL]: 1
vdev_stats.vs_ops[ZIO_TYPE_READ]: 1835587
vdev_stats.vs_ops[ZIO_TYPE_WRITE]: 646427
vdev_stats.vs_ops[ZIO_TYPE_FREE]: 0
vdev_stats.vs_ops[ZIO_TYPE_CLAIM]: 0
vdev_stats.vs_ops[ZIO_TYPE_IOCTL]: 7185
vdev_stats.vs_bytes[ZIO_TYPE_NULL]: 0
vdev_stats.vs_bytes[ZIO_TYPE_READ]: 238795578368
vdev_stats.vs_bytes[ZIO_TYPE_WRITE]: 65714164736
vdev_stats.vs_bytes[ZIO_TYPE_FREE]: 0
vdev_stats.vs_bytes[ZIO_TYPE_CLAIM]: 0
vdev_stats.vs_bytes[ZIO_TYPE_IOCTL]: 0
vdev_stats.vs_read_errors: 0
vdev_stats.vs_write_errors: 0
vdev_stats.vs_checksum_errors: 0
vdev_stats.vs_self_healed: 0
type: 'disk'
id: 0
path: '/dev/dsk/c0d0s7'
path: 'id1,cmdk@AMaxtor_6L200P0=L41FZEGH/h'
path: '/pci@0,0/pci-ide@1f,1/ide@0/cmdk@0,0:h'
vdev_stats.vs_timestamp: 693868 seconds
vdev_stats.vs_ops[ZIO_TYPE_NULL]: 1
vdev_stats.vs_ops[ZIO_TYPE_READ]: 1835587
vdev_stats.vs_ops[ZIO_TYPE_WRITE]: 646427
vdev_stats.vs_ops[ZIO_TYPE_FREE]: 0
vdev_stats.vs_ops[ZIO_TYPE_CLAIM]: 0
vdev_stats.vs_ops[ZIO_TYPE_IOCTL]: 7185
vdev_stats.vs_bytes[ZIO_TYPE_NULL]: 0
vdev_stats.vs_bytes[ZIO_TYPE_READ]: 238795578368
vdev_stats.vs_bytes[ZIO_TYPE_WRITE]: 65714164736
vdev_stats.vs_bytes[ZIO_TYPE_FREE]: 0
vdev_stats.vs_bytes[ZIO_TYPE_CLAIM]: 0
vdev_stats.vs_bytes[ZIO_TYPE_IOCTL]: 0
vdev_stats.vs_read_errors: 0
vdev_stats.vs_write_errors: 0
vdev_stats.vs_checksum_errors: 0
vdev_stats.vs_self_healed: 0

You get basically the same information as from "zpool iostat", but before averaging, so you can a) calculate an average I/O size, and b) extract the figures, do something (for a longer while), extract the figures again and get an average figure for exactly this time period.

DISCLAIMER:
a) This code uses private interfaces of Solaris. It is not portable across releases. In fact, you will have to compile seperately for each release.
b) This is not the proper way to seriously gather information for performance-tuning or so. For this purpose, use real weapons. Like "dtrace".
c) I have written this for my own educational purposes (to learn about the libzfs interfaces and nvpairs and ZFS internals in general). I do not claim fitness for any particular purpose...

I have just written a small onefifty-liner to check the physical block size of disk devices on Solaris. I have done this to show that the WD20EARS does indeed (erroneously!) report a physical sector size of 512 bytes.

See: blocksize.c (Source) and blocksize (binary, compiled on Solaris 10/x86).

Note that on the x86 platform, this will only work if the disks are attached to the sd driver (because the DKIOCGMEDIAINFOEXT ioctl is implemented only there and not in the cmdk driver). This will be the case if you use an AHCI controller supported by ahci(7d).

In my case (this is on 5.10 Generic_142910-17)

root@ilbirs> format -e </dev/null | egrep "[0-9]\."
0. c0t0d0 <DEFAULT cyl 30390 alt 2 hd 255 sec 63>
1. c0t1d0 <ATA-Hitachi HDS72107-A70M-698.64GB>
2. c0t3d0 <ATA-WDC WD20EARS-00M-AB50-1.82TB>
3. c0t4d0 <ATA-Hitachi HDS72107-A70M-698.64GB>

root@ilbirs> ./blocksize /dev/rdsk/c0t3d0
dkmp.dki_capacity = 3907029167
dkmp.dki_lbsize = 512
dkmp_ext.dki_capacity = 3907029167
dkmp_ext.dki_lbsize = 512
dkmp_ext.dki_pbsize = 512
root@ilbirs> ./blocksize /dev/rdsk/c0t4d0
dkmp.dki_capacity = 1465149167
dkmp.dki_lbsize = 512
dkmp_ext.dki_capacity = 1465149167
dkmp_ext.dki_lbsize = 512
dkmp_ext.dki_pbsize = 512

The above WD20EARS is revision "00MVWB0". I have another one at revision "00J2GB0", unfortunately hanging on a controller unsupported by ahci(7d).

If anybody has a WDxxEARS correctly reporting a dki_pbsize = 4096, I would love to hear it.

Edit:
If anybody has a Samsung HD204UI, I would also like to know if this disk correctly reports the physical block size.

I am in the process of trying out Solaris 10 09/10 (s10u9) on my machines, and encountered problems on my Dell PowerEdge 840 Server. The NIC on that box is a Broadcom 5721.

The NIC does come up, but only receives broadcast and multicast packets, not unicast ones.

As a workaround, I am using the driver from Solaris 10 10/09 (s10u8), which works fine.

Update 02.02.2011:

Problem solved!! I tried to install Solaris 11 Express on this machine and again the NIC wouldn't work. This time I tried a bit harder and found out that I had disabled the PXE Extensions for the NIC in the BIOS. After switching the PXE Extensions back on, it works!

Must be some subtle initialization problem.

Until recently, some nasty pointer arithmetic/type conversion in httpd led to a miscompilation by newer gcc's on x86. See here and here for more information.

This patch is already included in httpd-2.2.17.

Something still seems to be wrong, however. When compiling with "-O2" and gcc-4.5.2, httpd would still fail for me (in https processing, http was doing fine). I tried one of the aforementioned workarounds (using "-O2 -fno-strict-aliasing") and the problem vanished.