NCQ blacklist

NCQ blacklist

[Andrea Bravetti]

Please add "WDC WD3200BEVT-22ZCT0" to the NCQ blacklist.

I had some performance problem and I added this line:

        { "WDC WD3200BEVT-22ZCT0", NULL, ATA_HORKAGE_NONCQ },

around line 4184 of drivers/ata/libata-core.c (linux 2.6.30),
and now it work quite well...

Also "WDC WD5000AACS-00ZUB0" may have this problem, but I can't be sure...
You can see here: "https://bugs.launchpad.net/ubuntu/+source/linux/+bug/343371"

bye,
Andrea

Re: NCQ blacklist

[Alan Cox]

On Mon, 15 Jun 2009 00:40:23 +0200
Andrea Bravetti <andreabravetti@gmail.com> wrote:

> Please add "WDC WD3200BEVT-22ZCT0" to the NCQ blacklist.
> 
> I had some performance problem and I added this line:
> 
>         { "WDC WD3200BEVT-22ZCT0", NULL, ATA_HORKAGE_NONCQ },
> 
> around line 4184 of drivers/ata/libata-core.c (linux 2.6.30),
> and now it work quite well...

Which controller, what firmware revision, what sort of performance problem

Before blacklisting a drive we really need a lot more data. In paticular
any error messages in dmesg. Ideally also two or three different systems
seeing the same problem (so we know the drive is really the root cause)

Alan

Re: NCQ blacklist

[Andrea Bravetti]

I have no error messages in dmesg.

When I read large files the system become painfully slow and unresponsive.

SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA
AHCI Controller (rev 02)

root@kubra:~# hdparm -i /dev/sda

/dev/sda:

 Model=WDC WD3200BEVT-22ZCT0  , FwRev=11.01A11, SerialNo=WD-WXE408FT4047
 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50
 BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=625142448
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
 AdvancedPM=yes: unknown setting WriteCache=enabled
 Drive conforms to: Unspecified:  ATA/ATAPI-1,2,3,4,5,6,7


Now that the drive is in blacklist the whole system work much better.

hdparm -I still report NCQ as enabled and I don't know if it's a problem,
but now I have:

root@kubra:~# cat /sys/block/sda/device/queue_depth
1
root@kubra:~# cat /sys/block/sda/device/queue_type
none

before:

root@kubra:~# cat /sys/block/sda/device/queue_depth
31
root@kubra:~# cat /sys/block/sda/device/queue_type
simple

I can run any type of test and collect any type of data you ask for.

sincerely,
Andrea Bravetti



On Mon, Jun 15, 2009 at 1:01 AM, Alan Cox<alan@lxorguk.ukuu.org.uk> wrote:
> On Mon, 15 Jun 2009 00:40:23 +0200
> Andrea Bravetti <andreabravetti@gmail.com> wrote:
>
>> Please add "WDC WD3200BEVT-22ZCT0" to the NCQ blacklist.
>>
>> I had some performance problem and I added this line:
>>
>>         { "WDC WD3200BEVT-22ZCT0", NULL, ATA_HORKAGE_NONCQ },
>>
>> around line 4184 of drivers/ata/libata-core.c (linux 2.6.30),
>> and now it work quite well...
>
> Which controller, what firmware revision, what sort of performance problem
>
> Before blacklisting a drive we really need a lot more data. In paticular
> any error messages in dmesg. Ideally also two or three different systems
> seeing the same problem (so we know the drive is really the root cause)
>
> Alan
>

Re: NCQ blacklist

[Mark Lord]

Andrea Bravetti wrote:
..
> hdparm -I still report NCQ as enabled and I don't know if it's a problem,
..

"hdparm -I" does no such thing.
It merely shows the maximum queue depth that the drive permits.

If you want to see what queue depth Linux is using for the drive,
then either look in sysfs, or let "hdparm -Q" do it for you.

Cheers

Re: NCQ blacklist

[Alan Cox]

On Mon, 15 Jun 2009 00:40:23 +0200
Andrea Bravetti <andreabravetti@gmail.com> wrote:

> Please add "WDC WD3200BEVT-22ZCT0" to the NCQ blacklist.
> 
> I had some performance problem and I added this line:
> 
>         { "WDC WD3200BEVT-22ZCT0", NULL, ATA_HORKAGE_NONCQ },

Following some off list discussion - NAK this.

There is something going on clearly but it doesn't appear to be the drive
but rather that the I/O patterns with NCQ (maybe the better performance)
are messing something else up.

Needs further exploration to see if this is vm, I/O scheduling or our
current libata lack of protection against drive firmware unfairness (as
the SCSI layer has)