NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/39686: NetBSD 4.x has I/O problems on HP Compaq DL38[0|5] w/ Smart Array 6i controller
The following reply was made to PR kern/39686; it has been noted by GNATS.
From: "Michael L. Hitch" <mhitch%lightning.msu.montana.edu@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: pettai%nordu.net@localhost
Subject: Re: kern/39686: NetBSD 4.x has I/O problems on HP Compaq DL38[0|5]
w/ Smart Array 6i controller
Date: Sun, 8 Aug 2010 20:51:06 -0600 (MDT)
I've recently acquired a DL360 G4p with a 6i controller and no
battery-backed cache, and started looking into this again. A tech-kern
thread started by Anders Magnusson,
http://mail-index.NetBSD.org/tech-kern/2008/11/30/msg003704.html , which I
had forgotten about, had some information on a problem with ciss(4). I
have been investigating and verified that ciss(4) was only getting one
command at a time. Another test with a Linux Live CD did show me that
when Linux was doing a dd to the disk, it was getting around 150 commands
queued to the ciss adapter, and resulted in a respectable write transfer
rate (how that is actually working with no write cache is a mystery to
me).
I was able to determine that the scsipi layer was only sending one
command at a time to the adapter. It was doing this because it will only
send multiple commands to the adapter if all the commands use tagged
queueing. Commenting out the check for non-tagged commands resulted in a
much better write performance under certain conditions - specifically by
using the log option on the file system. [That will keep a lot of the
disk pages in the buffer cache, and writes them out asynchronously,
allowing multiple write commands to the disk.]
I then determined that the reason for the untagged commands was that
tagged queueing was that ciss(4) was not telling the scsipi layer to used
tagged queueing. There's a problem with doing that though - the
capabilities for the drive(s) don't include tagged queuing because the
implementation of the Inquiry command by Compaq/HP in the ciss adapter is,
uh, lacking. It sets the CmdQue bit that indicates is supports tagged
queuing, but doesn't set the version field to indicate that the additional
flags in the inquiry data is valid, and NetBSD happily ignores it. I'm
now working on getting ciss(4) to force tagged queueing, which should help
this performance problem.
--
Michael L. Hitch mhitch%montana.edu@localhost
Computer Consultant
Information Technology Center
Montana State University Bozeman, MT USA
Home |
Main Index |
Thread Index |
Old Index