[ILUG] Mandrake 10

[Paul Jakma]

On Tue, 27 Apr 2004, Rick Moen wrote:

> Don't forget additional ports to support up to 15 drives per host,

Is that not possible already? Can you not put 3 8-port controllers 
into a host? (or are you referring to the port multiplier spec? To 
allow 15 SATA ports to be multiplex to one HBA port)

> failover switches, 

Interesting. There's also dual-port/multi-path specification being 
worked on. SCSI doesnt have that at all.

> external connectors, and doubling of the theoretical bus bandwidth.

Yeah, only way beyond SCSI. but hey.

> But the drives themselves seem, even then, likely to remain
> underdesigned windup toys

I fail to understand why this would be so.

> heavily reliant on write-back caching to maintain even a semblance
> of reasonable performance

As far as i can tell you are now, based on a vague article and (old)  
discussions on linux-kernel concerning specific ranges of drives,
generalising for all S-ATA drives. I dont think this is a safe
generalisation. Further, I dont see why use of write-back caching to
gain performance is a sole concern or specific to S-ATA, other than:

- some drives used to lie about disabling it, the hoopla surrounding 
this has apparently persuaded vendors of the error of their ways.

- ATA drives are _way_ bigger than SCSI drives :) and hence are 
increasingly more sensitive to cache.

You're trying to brand S-ATA as bogus because of past implementation
defects of vendors trying to chase the price/performance market.  
Brand the vendors, fair enough, but generalising to an interface
technology is simply nonsensical.

> -- which is especially damning in environments with significant
> multitasking, multithreading, or multiuser access.  Like, say,
> Unix.

Err, increased write-performance _helps_ for multi-user environments
(helps for any environment). It's a data-integrity problem on power
loss. Dont buy drives that lie about write caching. (write-through
caching isnt interesting or worth calling write caching, that's just
a free read cache - up to the drives operating system to decide how
best to cache things, provided it doesnt lie about write caching.).

> See previously cited article.

Yadah yadah, yes we read the article.
 
> Speaking of interfaces, I wonder how many of the excited early
> adopters were aware that almost all so-called SATA drives for the
> first year were literally the same old ATA/133 models with Marvell
> Technology Group PATA-to-SATA bridge chips tacked on?

Doesnt matter really. The intention with SATA 1.0a was to allow 
bridging as an easy transition mechanism.

> (http://www.kerneltraffic.org/kernel-traffic/kt20040418_258.html#9):
> "limit SII to UDMA5 (reading info on FreeBSD lists and source code
> scared me about chip errata), mainly related to PATA->SATA
> bridges."

hey, that's interesting (seeing as how my 2 sil3112a cards arrived
this morning). OTOH, the 'sata performance' thread had someone
trading posts with Jeff to improve sata_sil performance, resulting in
poster finally getting to point where he hit PCI bandwidth limit :)

> Yeah, that's quality.

Talk to Niall O'Broin about how wonderful SCSI controllers are.

I had 2 IBM drives die on me in the space of a month (in the same 
array). 

The stated goal of the S-ATA backers (Intel, Dell, Seagate, Maxtor,
etc.) is to have it move into the high-end. There's nothing in the
_interface_ to stop it. There's only quality of implementation of
standard required for "enterprise", which will be there given the
backers.

regards,
-- 
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
	warning: do not ever send email to spam at dishone.st
Fortune:
Half the world is composed of people who have something to say and can't,
and the other half who have nothing to say and keep on saying it.