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