Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Robert Hancock]

Linda Walsh wrote:
> Robert Hancock wrote:
>> Linda Walsh wrote:
>>> Alan Cox wrote:
>>>>> rate began falling; at 128k block-reads-at-a-time or larger, it 
>>>>> drops below
>>>>> 20MB/s (only on buffered SATA).
>>>> Try disabling NCQ - see if you've got a drive with the 'NCQ = no
>>>> readahead' flaw.
>> http://linux-ata.org/faq.html#ncq
> ---
>    When drive initializes, dmesg says it has NCQ (depth 0/32)
>    Reading the queue_depth under /sys, shows a queuedepth of "1".

Looks like your controller (or at least the Linux driver) doesn't 
actually support NCQ.

>>> 2) Drive Advanced Power Management setting("-B") (write-only):
>>> "HDIO_DRIVE_CMD failed: Input/output error"
>>> 3) Drive Acoustic ("-M"), read = " acoustic      = not supported",
>>> write = " HDIO_DRIVE_CMD:ACOUSTIC failed: Input/output error"
>>
>> Not sure about these ones.. Does anything show up in dmesg when you do 
>> this?
> ---
>    Yes:
>    (for "-B", power-management)
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
> ata1.00: port_status 0x20200000
> ata1.00: cmd ef/05:fe:00:00:00/00:00:00:00:00/40 tag 0 cdb 0x0 data 0
>         res 51/04:fe:00:00:00/00:00:00:00:00/40 Emask 0x1 (device error)
> ata1.00: configured for UDMA/133
> ata1: EH complete
> sd 1:0:0:0: [sdb] 1465149168 512-byte hardware sectors (750156 MB)
> sd 1:0:0:0: [sdb] Write Protect is off
> sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
> sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't 
> support DPO or FUA
> ----
>   (for "-M" acoustic management):
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
> ata1.00: port_status 0x20200000
> ata1.00: cmd ef/42:fe:00:00:00/00:00:00:00:00/40 tag 0 cdb 0x0 data 0
>         res 51/04:fe:00:00:00/00:00:00:00:00/40 Emask 0x1 (device error)
> ata1.00: configured for UDMA/133
> ata1: EH complete
> sd 1:0:0:0: [sdb] 1465149168 512-byte hardware sectors (750156 MB)
> sd 1:0:0:0: [sdb] Write Protect is off
> sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
> sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't 
> support DPO or FUA

Looks like the drive reports ERR/ABRT (command aborted), meaning it 
likely doesn't support those commands.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Linda Walsh]

Robert Hancock wrote:
>
> Looks like the drive reports ERR/ABRT (command aborted), meaning it 
> likely doesn't support those commands.
>
---
    Except the PATA version of the drive does (same capacity, & other 
specs).  Seagate would
disable "advanced" features for SATA but leave them for the older 
technology?  Possible,
but doesn't seem likely.

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Robert Hancock]

Linda Walsh wrote:
> Robert Hancock wrote:
>>
>> Looks like the drive reports ERR/ABRT (command aborted), meaning it 
>> likely doesn't support those commands.
>>
> ---
>    Except the PATA version of the drive does (same capacity, & other 
> specs).  Seagate would
> disable "advanced" features for SATA but leave them for the older 
> technology?  Possible,
> but doesn't seem likely.

If this is a Seagate, I believe that they don't have AAM enabled on any 
of their newer drives (something about a lawsuit for patent infringement 
on that feature, or something). Quite likely they don't support that 
power management command, either.

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Linda Walsh]

Robert Hancock wrote:
>
> If this is a Seagate, I believe that they don't have AAM enabled on 
> any of their newer drives (something about a lawsuit for patent 
> infringement on that feature, or something). Quite likely they don't 
> support that power management command, either.
--
    Do you have a source for this -- haven't heard of such a conflict -- 
besides, doesn't
ATA-7 require some of those functions?  Given the trend toward 
power-saving and
quieter (also usually less vibration)  hard disks, I strongly disbelieve 
Seagate would
remove those features -- especially since they are mentioned on 
Seagate's drive
information page as being supported features.

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Mehmet Kemal EROL]

Linda Walsh:

> 
> Seagate would
> remove those features -- especially since they are mentioned on 
> Seagate's drive
> information page as being supported features.
> 

Since you're there ... you might want to download `Seagate's SeaTools'
and (if) give the hdd's controller a try ... ;)

-- 
Esenlikle   <~>   Mehmet Kemal

_/_/  IBM Pollyanna Principle:
_/    Machines should work,
_/    People should think...

Re: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Alan Cox]

On Sun, 06 Jan 2008 12:25:10 -0800
Linda Walsh <lkml@tlinx.org> wrote:

> Robert Hancock wrote:
> >
> > If this is a Seagate, I believe that they don't have AAM enabled on 
> > any of their newer drives (something about a lawsuit for patent 
> > infringement on that feature, or something). Quite likely they don't 
> > support that power management command, either.
> --
>     Do you have a source for this -- haven't heard of such a conflict -- 

There were patent questions around AAM. There are some discussions on the
t13 archive then it goes silent and nothing is ever said again, which I
imagine is when it got lawyered.

> besides, doesn't
> ATA-7 require some of those functions? 

No.

Alan

Re: Believed resolved: SATA kern-buffRd read slow: based on promise driver bug

[Robert Hancock]

Linda Walsh wrote:
> Mikael Pettersson wrote:
>> Linda Walsh writes:
>>  > Mikael Pettersson wrote:
>>  > > Linda Walsh writes:
>>  > >  > > Linda Walsh wrote:
>>  > >  > >>>> read rate began falling; (.25 - .3);  > >  > more 
>> importantly; a chronic error message associated
>>  > >  > with drive may be causing some or all of the problem(s):
>>  > >  > ---
>>  > >  > ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
>>  > >  > ata1.00: port_status 0x20080000
>>  > >  > ata1.00: cmd c8/00:10:30:06:03/00:00:00:00:00/e0 tag 0 cdb 0x0 
>> data 8192 in
>>  > >  >          res 50/00:00:3f:06:03/00:00:00:00:00/e0 Emask 0x2 
>> (HSM violation)
>>  > >  > ata1: limiting SATA link speed to 1.5 Gbps
>>  > >
>>  > > Looks like the Promise ASIC SG bug. Apply
>>  > > 
>> <http://user.it.uu.se/~mikpe/linux/patches/sata_promise/patch-sata_promise-1-asic-sg-bug-fix-v3-2.6.23> 
>>
>>  > > and let us know if things improve.
>>  > > /Mikael
>>  > ---
>>  >     Yep!  Hope that's making it into a patch soon or, at least 2.6.24.
>>  >     Kernel buffered
>> Good to hear that it solved this problem.
>> The patch is in 2.6.24-rc2 and newer kernels, and will be sent
>> to -stable for the 2.6.23 and 2.6.22 series.
>>   
> ---
>    Will 'likely' wait till -stable since I use the machine as a 'server'
> for just about any/everything that needs "serving" or "proxy" services.
>>  >  That and I'd like to find out why TCQ/NCQ doesn't work with the 
>> Seagate drives --
>>
>> The driver doesn't yet support NCQ.
> ----
>    Is 'main' diff between NCQ/TCQ that TCQ can re-arrange 'write'
> priority under driver control, whereas NCQ is mostly a FIFO queue?

First off one has to distinguish between ATA TCQ and SCSI TCQ. ATA TCQ 
is essentially abandoned, very few drives and fewer still controllers 
and matching drivers ever supported it.

SCSI TCQ has "head of queue", "ordered" and "simple" queueing modes. ATA 
NCQ effectively only has "simple" where the drive always decides what 
order to service the requests in. There is a FUA mode, which tells the 
drive that the command (normally a write) has to access the physical 
media before reporting completion.

> 
>    On a Journal'ed file system, isn't "write-order" control required
> for integrity?  That would seem to imply TCQ could be used, but
> NCQ doesn't seem to offer much benefit, since the higher level
> kernel drivers usually have a "larger picture" of sectors that need
> to be written.  The only advantage I can see for NCQ drives might

There are cases where writes need to complete in a specific order. This 
can be done either by using FUA bits (though libata doesn't do this by 
default currently) or by issuing cache flushes before and after certain 
commands.

> be that the kernel may not know the drive's internal physical
> structure nor where the disk is in its current revolution.  That could
> allow drive write re-ordering where based on the exact-current state
> of the drive that the kernel might not have access to, but it seems
> this would be a minor benefit -- and, depending on firmware,
> possibly higher overhead in command processing?

That's a big part of it. The kernel doesn't necessarily know what 
sectors will be the fastest to access at any given time whereas the 
drive can.

Also, NCQ has some other improvements that are independent of actually 
queueing commands - for instance, because the drive controls the DMA 
data transfer, it can transfer the data for one request in an 
out-of-order fashion instead of having to transfer to the host strictly 
from beginning to end as in traditional ATA.

> 
> Am trying to differentiate NCQ/TCQ and SAS v. SCSI benefits.
> It seems both support (SAS & SATA) some type of port-multiplier/
> multiplexor/ option to allow more disks/port.
> 
> However, (please correct?) SATA uses a hub type architecture while
> SAS uses a switch architecture.  My experience with network hubs vs.
> switches is that network hubs can be much slower if there is
> communication contention.  Is the word 'hub' being used in the
> "shared-communication media sense", or is someone using the term
> 'hub' as a [sic] replacement for a 'switch'?

I believe that they're essentially the same in that regard, though 
someone can correct me if I'm wrong..

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: Believed resolved: SATA kern-buffRd read slow: based on promise driver bug

[Tejun Heo]

Linda Walsh wrote:
>    Is 'main' diff between NCQ/TCQ that TCQ can re-arrange 'write'
> priority under driver control, whereas NCQ is mostly a FIFO queue?

No, NCQ can reorder although I recently heard that windows issues
overlapping NCQ commands and expects them to be processed in order (what
were they thinking?).

The biggest difference between TCQ and NCQ is that TCQ is for SCSI while
NCQ is for ATA.  Functional difference includes more number of available
tags and ordered tags for TCQ.  The former doesn't matter for single
disk.  The latter may make some difference but on single disk not by much.

> Am trying to differentiate NCQ/TCQ and SAS v. SCSI benefits.
> It seems both support (SAS & SATA) some type of port-multiplier/
> multiplexor/ option to allow more disks/port.
> 
> However, (please correct?) SATA uses a hub type architecture while
> SAS uses a switch architecture.  My experience with network hubs vs.
> switches is that network hubs can be much slower if there is
> communication contention.  Is the word 'hub' being used in the
> "shared-communication media sense", or is someone using the term
> 'hub' as a [sic] replacement for a 'switch'?

Port multiplier is a switch too.  It doesn't broadcast anything and
definitely has forwarding buffers inside.  An allegory which makes more
sense is expander to router and port multiplier to switch.  Unless you
wanna nest them, they aren't that different.

-- 
tejun

Re: Believed resolved: SATA kern-buffRd read slow: based on promise driver bug

[Linda Walsh]

Mikael Pettersson wrote:
> Linda Walsh writes:
>  > Mikael Pettersson wrote:
>  > > Linda Walsh writes:
>  > >  > > Linda Walsh wrote:
>  > >  > >>>> read rate began falling; (.25 - .3); 
>  > >  > more importantly; a chronic error message associated
>  > >  > with drive may be causing some or all of the problem(s):
>  > >  > ---
>  > >  > ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
>  > >  > ata1.00: port_status 0x20080000
>  > >  > ata1.00: cmd c8/00:10:30:06:03/00:00:00:00:00/e0 tag 0 cdb 0x0 data 8192 in
>  > >  >          res 50/00:00:3f:06:03/00:00:00:00:00/e0 Emask 0x2 (HSM violation)
>  > >  > ata1: limiting SATA link speed to 1.5 Gbps
>  > >
>  > > Looks like the Promise ASIC SG bug. Apply
>  > > <http://user.it.uu.se/~mikpe/linux/patches/sata_promise/patch-sata_promise-1-asic-sg-bug-fix-v3-2.6.23>
>  > > and let us know if things improve.
>  > > /Mikael
>  > ---
>  >     Yep!  Hope that's making it into a patch soon or, at least 2.6.24.
>  >     Kernel buffered
> Good to hear that it solved this problem.
> The patch is in 2.6.24-rc2 and newer kernels, and will be sent
> to -stable for the 2.6.23 and 2.6.22 series.
>   
---
    Will 'likely' wait till -stable since I use the machine as a 'server'
for just about any/everything that needs "serving" or "proxy" services.
>  >  That and I'd like to find out why TCQ/NCQ doesn't work with the Seagate drives --
>
> The driver doesn't yet support NCQ.
----
    Is 'main' diff between NCQ/TCQ that TCQ can re-arrange 'write'
priority under driver control, whereas NCQ is mostly a FIFO queue?

    On a Journal'ed file system, isn't "write-order" control required
for integrity?  That would seem to imply TCQ could be used, but
NCQ doesn't seem to offer much benefit, since the higher level
kernel drivers usually have a "larger picture" of sectors that need
to be written.  The only advantage I can see for NCQ drives might
be that the kernel may not know the drive's internal physical
structure nor where the disk is in its current revolution.  That could
allow drive write re-ordering where based on the exact-current state
of the drive that the kernel might not have access to, but it seems
this would be a minor benefit -- and, depending on firmware,
possibly higher overhead in command processing?

Am trying to differentiate NCQ/TCQ and SAS v. SCSI benefits.
It seems both support (SAS & SATA) some type of port-multiplier/
multiplexor/ option to allow more disks/port.

However, (please correct?) SATA uses a hub type architecture while
SAS uses a switch architecture.  My experience with network hubs vs.
switches is that network hubs can be much slower if there is
communication contention.  Is the word 'hub' being used in the
"shared-communication media sense", or is someone using the term
'hub' as a [sic] replacement for a 'switch'?

Re: Believed resolved: SATA kern-buffRd read slow: based on promise driver bug

[Robert Hancock]

Linda Walsh wrote:
>    I seem to remember reading about some problems with Promise SATA & ACPI.
> Does this address that or is that a separate issue?  (Am using no-acpi for
> now, but would like to try acpi again if it may be fixed (last time I tried
> it with this card, "sdb" went "offline" (once it unmounted itself and
> refused to be remounted (no error...just nothing), and another it stayed
> mounted, but gave an I/O Error...so have been using no-acpi since).
> An ACPI error in bootup said:
> ACPI Exception (utmutex-0263): AE_BAD_PARAMETER, Thread EFFC2000 could 
> not acquire Mutex [3] [20070126]

Have you tried 2.6.24-rc6? If the problem still occurs there, you should 
post the full bootup log.

> 
>    Is the above bug mentioned/discussed in the linux-ide archives?  That
> and I'd like to find out why TCQ/NCQ doesn't work with the Seagate 
> drives --
> my guess, since they say queuedepth of 0/32, is that they are blacklisted
> as being drives that don't follow normal protocol or implement their
> own proprietary extensions?  Sigh.  Really a lame move (if that's the case)
> for Seagate, considering they usage they could likely get in server
> configs.  Maybe they want to push their SCSI/SAS drives?

Queue depth 0/32 means the drive supports a queue depth of 32 but the 
controller/driver don't support NCQ.

>    BTW, can SATA have DPO or FUA or are those limited to SCSI?
> Would it be a desirable future addition to remove the
> "doesn't support DPO or FUA" error message" on SATA drives if they are
> specific to SCSI?

ATA disks can have FUA support, but the support is disabled in libata by 
default. (There's a fua parameter on libata module to enable it I believe.)