Poor / buggy performance with the mpt driver in 8.1 AMD64?

[Dean Hamstead]

My experience is that ZFS performance is miserable compared to UFS.

I found that GEOM raid5 with UFS was more than 2x faster than ZFS on the 
same controller, same disks etc.

That aside, something looks seriously screwy with your raid card.

I assume youve covered the basics? update the firmware, check cables etc?

Youre confident that the hard is in the right mode? That all firmware 
settings of the card are reasonably sane?

Dean

On 09/12/10 09:02, Mattias Lindgren wrote:
> I have 8 Seagate SATA disks connected to an intel branded LSI 3081E
> SAS controller (Intel SASUC8I).  I have 4 of the 1.5T disks and I have
> 4 2T disks (both are the LP 5900RPM variety) in a pair of raidz1s in a
> ZFS pool.  Doing simple dd writes and reads I get about 80MByte write
> and 150MByte read which seems very very slow to me.  I'm also getting
> errors from mpt on boot:
>
> #dmesg |grep mpt
>
> mpt0:<LSILogic SAS/SATA Adapter>  port 0xc800-0xc8ff mem
> 0xfe9fc000-0xfe9fffff,0xfe9e0000-0xfe9effff irq 16 at device 0.0 on
> pci1
> mpt0: [ITHREAD]
> mpt0: MPI Version=1.5.19.0
> mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 )
> mpt0: 0 Active Volumes (2 Max)
> mpt0: 0 Hidden Drive Members (14 Max)
> da0 at mpt0 bus 0 scbus0 target 0 lun 0
> da1 at mpt0 bus 0 scbus0 target 1 lun 0
> da2 at mpt0 bus 0 scbus0 target 2 lun 0
> da3 at mpt0 bus 0 scbus0 target 3 lun 0
> da4 at mpt0 bus 0 scbus0 target 4 lun 0
> da5 at mpt0 bus 0 scbus0 target 5 lun 0
> da6 at mpt0 bus 0 scbus0 target 6 lun 0
> da7 at mpt0 bus 0 scbus0 target 7 lun 0
> mpt0: request 0xffffff80003aedc0:8885 timed out for ccb
> 0xffffff00020a7800 (req->ccb 0xffffff00020a7800)
> mpt0: attempting to abort req 0xffffff80003aedc0:8885 function 0
> mpt0: mpt_wait_req(1) timed out
> mpt0: mpt_recover_commands: abort timed-out. Resetting controller
> mpt0: mpt_cam_event: 0x0
> mpt0: mpt_cam_event: 0x0
> mpt0: completing timedout/aborted req 0xffffff80003aedc0:8885
> mpt0: mpt_cam_event: 0x16
> mpt0: mpt_cam_event: 0x12
> mpt0: mpt_cam_event: 0x12
> mpt0: mpt_cam_event: 0x12
> mpt0: mpt_cam_event: 0x12
> mpt0: mpt_cam_event: 0x12
> mpt0: mpt_cam_event: 0x12
> mpt0: mpt_cam_event: 0x12
> mpt0: mpt_cam_event: 0x12
> mpt0: mpt_cam_event: 0x16
> mpt0: request 0xffffff80003b6110:9108 timed out for ccb
> 0xffffff00085fc800 (req->ccb 0xffffff00085fc800)
> mpt0: attempting to abort req 0xffffff80003b6110:9108 function 0
> mpt0: mpt_wait_req(1) timed out
> mpt0: mpt_recover_commands: abort timed-out. Resetting controller
> mpt0: mpt_cam_event: 0x0
> mpt0: completing timedout/aborted req 0xffffff80003b6110:9108
> mpt0: mpt_cam_event: 0x16
> mpt0: mpt_cam_event: 0x12
> mpt0: mpt_cam_event: 0x12
> mpt0: mpt_cam_event: 0x16
> mpt0: mpt_cam_event: 0x12
> mpt0: mpt_cam_event: 0x12
> mpt0: mpt_cam_event: 0x12
> mpt0: mpt_cam_event: 0x12
> mpt0: mpt_cam_event: 0x12
> mpt0: mpt_cam_event: 0x12
> mpt0: mpt_cam_event: 0x16
> mpt0: request 0xffffff80003ac8a0:9287 timed out for ccb
> 0xffffff000857d000 (req->ccb 0xffffff000857d000)
> mpt0: attempting to abort req 0xffffff80003ac8a0:9287 function 0
> mpt0: mpt_wait_req(1) timed out
> mpt0: mpt_recover_commands: abort timed-out. Resetting controller
> mpt0: mpt_cam_event: 0x0
> mpt0: completing timedout/aborted req 0xffffff80003ac8a0:9287
> mpt0: mpt_cam_event: 0x16
> mpt0: mpt_cam_event: 0x12
> mpt0: mpt_cam_event: 0x12
> mpt0: mpt_cam_event: 0x16
> mpt0: mpt_cam_event: 0x16
> mpt0: mpt_cam_event: 0x12
> mpt0: mpt_cam_event: 0x12
>
> etc
>
> I'm running a vanilla version of FreeBSD with no special kernel patches.
>
> FreeBSD beastie 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19
> 02:36:49 UTC 2010
> root at mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
>
> I have the following in /boot/loader.conf per the FreeBSD ZFS tuning
> guide pertaining to NFS shares:
>
> vfs.zfs.zil_disable="1"
>
> Does anyone have any thoughts on getting rid of the cam event error as
> well as my performance numbers?  Other people with comparable systems
> are reporting dd numbers that are twice what I'm seeing.
> _______________________________________________
> freebsd-hardware at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
> To unsubscribe, send any mail to "freebsd-hardware-unsubscribe at freebsd.org"
>