SATA

SATA-I gives 150 MB/s, SATA-II gives 300 MB/s, PATA 133 MB/s.

PATA: poor performance in general, but lousy if you have two drives on one controller. Since most boards have only 1 or two controllers, that's one or two drives. PATA bandwidth is per controller. Cable lenghth: 18", wide ribbon blocks air flow.

SATA: Being serial, each cable is point-to-point, so bandwidth is per drive. Cable length 39" (1 m).

Debian Etch has full support for SATA.

If you want to edit videos, go with SATA. If you can afford it, you may want to go with two drives and set up LVM with a stripped LV (or use raid0) to speed up the drive access.

Doug @porchlight.ca

PATA/133 was a flaky kludge. It's amazing it worked at all. Even more amazing that people got away with cables over 18" long. SATA is a far superior interconnect.

The instantaneous peak throughput of the original (four bytes wide, 33 MHz) PCI bus is 132 MB/sec. In real life you're not going to see over 90. So a SATA-II controller on a regular PCI card is bottlenecked at the motherboard slot. (So is 1000BASE-T Ethernet.) That's one reason "real hardware" RAID works better than "fakeraid." The smallest PCI Express (PCI-E) configuration should do 250 MB/sec in each direction simultaneously. A motherboard with PCI-E designed for workstations may bottleneck at the southbridge.

You'll have to do some research to find a configuration that can run two SATA-II drives simultaneously at their full data rate. You'll also have to check around to see if the Linux driver knows how to run any particular controller in SATA-II mode. And there are still lots of workstation type motherboards that only do SATA-I.

PCI-X is a kludge. I'd avoid it.

Cameron @truffula.sj.ca.us

http://wiki.linuxquestions.org/wiki/SATA

Serial ATA, also known as SATA or S-ATA, is a bus used to communicate between the CPU and internal storage devices such as hard drives and optical drives. It is designed to eventually replace the ATA (also known as IDE) bus. Traditional ATA is beginning to be referred to as Parrellel ATA, P-ATA, or PATA to avoid confusion.

The main difference between SATA and PATA is in the cabling. SATA does away with the master/slave relationship of PATA (hence the difference in names), as well as PATA's ungainly ribbon cables. Instead, SATA has much slimmer and easier to manage cables, which will enable better airflow through cases. The connectors are keyed, preventing connectors from being plugged upside down. Truly native SATA drives will have different power connectors also.

A third advantage of SATA is hotplugging.

Currently, SATA has a transfer rate of 150 MB/s, which is only 17 MB/s more than standard PATA. However, with the introduction of SATA II, this is expected to go up to 300 MB/s, with 600 MB/s being released sometime around 2007. The faster bus isn't expected to affect performance in the short term, since hard drive performance is usually bottlenecked by the moving parts of the drive.

During the transitional period before true native SATA drives are released, most SATA drives actually have onboard PATA controllers, which connect to SATA by a bridge. This generally causes a 30-50% performance drop. Also, PATA power connectors are still being used.

Support for SATA was introduced in Linux kernel 2.4.27. In the modern 2.6 kernel, SATA support is available through the libata driver. Currently, the core driver and a number of chipset drivers are production-level stable, but the core lacks support for a number of SATA features, such as SMART support, PATA support for extra PATA ports on some SATA cards (except for a few cards), ATAPI support for SATA CD/DVD-ROMs, hotplugging, and TCQ/NCQ queueing. All of these features are being worked on.

Jeff Garzik has detailed information on the current Linux SATA status at his page, http://linux.yyz.us/sata/.

This page was last modified 06:03, May 23, 2005.

documented on: 2005.07.31

http://www.dvdoctor.net/content/item.php?item=1006

Serial ATA is rapidly taking over from parallel ATA in desktop PCs. James Morris explains why we need this new hard-disk connection

One clear recent trend across PCs on all platforms is the arrival of new-generation serial interfaces to replace long-established parallel interfaces (and old-style serial interfaces, too).

On Macs, USB and FireWire serial interfaces have taken over from adb. On IBM PC-compatibles, USB is replacing or being fitted alongside the old 25-pin parallel port and the nine-pin serial port, while FireWire is finally starting to become standard, as well. In addition, the serial PCI Express motherboard bus is beginning to take over from parallel PCI.

Also on its way out is the IDE/parallel ATA (Pata) connection thats been with PCs in a variety of guises since IBM personal computers first came with hard disks.

Its replacement, Serial ATA (Sata), has been working its way onto motherboards and is now almost universal in new PCs. New-generation Macs, though, still carry IDE for connecting optical drives and burners, whether DVD or CD, and so do most Windows PC motherboards.

Satas seven-wire data cable is much smaller than Patas 40/80-wire cable and helps airflow around the case. But the tiny data plug is far less rugged than Patas and liable to break after multiple insertions

The Sata data and power connections are alongside one another to provide a single-plug quick-release option. On some Sata drives there is also an old-style power socket for backwards compatibility with the Molex connectors still standard on many PC power supplies

Pata has been through various incarnations, increasing in bandwidth every few years. In Pentium I days, it was capable of 16.6MByte/sec, but this was raised using DMA modes to 33MByte/sec via the Ultra-ATA standard. Then came Ultra-ATA/66 with 66MByte/sec and Ultra-ATA/100 with 100MByte/sec.

Some motherboard makers have moved to using Ultra-ATA/133, offering 133MByte/sec bandwidth. Maxtor is the main supporter of this upgraded form of Pata - Hitachi has remained with Ultra-ATA/100. Since Ultra-ATA/66, the cable changed from 40 wires to 80, although the extra wires operate through the same 40-pin connector as before for backwards compatibility.

However, all these Pata performance figures are nominal. In reality, no form of Pata can sustain its maximum rated throughput. Maxtor, for example, admits that Ultra-ATA/133 can only achieve 85 per cent of its bandwidth, and even then only in burst mode. The overhead from control signalling reduces the real figure considerably.

And, though a single Pata channel can usually support two devices - typically configured as master and slave - they have to share the channel's bandwidth, though this currently isn't a major problem.

Few hard disks exceed 50MByte/sec average sustained data transfer rate and the interface can cope with around 100MByte/sec. But there's clearly not much future left for Pata when Ultra-ATA/133 maxes out at a little over 110MByte/sec.

A few Pata drives are able to sustain well over 50MByte/sec, such as Western Digital's Raptor, Seagate's 200GByte Barracuda 7200.7 and Maxtor's DiamondMax 10. Other makers will follow with their next-generation models.

So anyone planning to use more than one disk on a single ATA channel, particularly in a Raid configuration, will discover that Pata isn't up to the job.

Image

Traditionally, the way around the Pata bottleneck has been to use SCSI, the Small Computer Systems Interface. Although SCSI is also a parallel connection, each new version has kept it way ahead of Pata.

As well as having a higher nominal bandwidth than Pata, SCSI has had intelligent circuitry in its adapters and drives that meant that most of the throughput could be used.

The current fastest SCSI standard, Ultra320, offers 320MByte/sec. However, like Pata, that's shared between all the devices on the SCSI channel.

But there can be up to 15 devices on a single SCSI connection, all sharing the 320MByte/sec, so the SCSI bus itself will start to be the limiting factor if more than five fast disks are attached such as Seagate's Cheetah X15 15,000rpm model.

SCSI also carries a big price premium - the disks can be four or five times more expensive than their Pata or Sata equivalents, and faster adaptors aren't cheap either.

Although Sata's nominal 150MByte/sec is slightly better than the bandwidth of Ultra-ATA/133, that's not the only reason why it has a rosy future ahead of it.

No less important is that Sata's 150MByte/sec is dedicated to just one device - and no current Sata hard disks require even half that.

The fastest Sata drive currently available, Western Digital's 10,000rpm Raptor, averages 65MByte/sec, so it will be a while before any disk starts to push the limits of Sata - by then there will be a new Mk II version, as detailed below.

The data and power cabling for Sata is completely different to Pata. Although the many Sata drives include the standard Molex power connector for backwards compatibility, there is a new Sata power plug that, like the Sata data connection, is an entirely new in-line format.

For those disks without a Molex power connector, it's necessary to use Molex-to-Sata power adapters or a PC power supply with Sata power plugs.

Image Molex-to-Sata power adapter

On a hard drive, the two new connectors sit side-by-side to simplify use with slide-in disk caddies. Understandably, though, many makers of servers and other high-end systems consider the connectors too fragile for this kind of use.

Sata has potentially huge benefits for Raid, compared with SCSI. Each Sata disc has its own dedicated 150MByte/sec pipe, so a Sata Raid set up doesn't suffer the same limitations of SCSI Raid systems where all drives have to share 320MByte/sec of bandwidth.

Unfortunately, though, with Sata, the bottleneck shifts to the motherboard's PCI bus. That's why most current Sata Raid adapters - particularly those with four or more ports - use PCI-X, the 64-bit (but still parallel) version of PCI that offers many times the bandwidth of standard PCI.

Most of these adapters can also be used in PCI slots, but are then limited to PCI's 133MBytes/sec ceiling.

The next version of Sata - Sata/300, also known as Sata II - will push the serial interface well beyond Pata, doubling maximum throughput to 300MBytes/sec. The physical-layer specification for Sata/300 was ratified in July 2004, and product is now starting to arrive.

But there's more to Sata II than raw performance. Other improvements are intended to increase throughput using more subtle means. Perhaps most important is Native Command Queuing (NCQ).

The idea of NCQ is that it boost performance by allowing a drive to optimise the order of the work that it carries out - ensuring that the heads travel across the drive's platters in the most efficient way for the fastest read/write speeds.

NCQ is already found in some Sata 1drives, including models from Seagate and Western Digital but WD's Raptor uses a derivative of the earlier Pata version, and it's not yet clear how compatible it will be with the full Sata II version.

Some Sata controllers are also available with NCQ support - including Pacific Digital's Talon ZL series and HighPoint's 1820 adapters - and it's built into Intel's integrated ICH6R controller, too.

However, the arrival of the Serial ATA II Extensions, will mean that NCQ becomes a standard feature of all Sata controllers. Sata II is also meant to bring about the hot-plug capabilities promised with the original version.

Also significant is the Port Multiplier function. This enables one Sata connection to handle up to four drives. As well as allowing multiple drives to be run from a single connection, it allows connections to be routed to a more convenient location and makes cabling tidier.

So, for instance, it might use one Sata/300 cable to route to a system-box backplane supporting up to four hot-plug hard disks. Supporting chipsets are already in production from companies such as Marvell (www.marvell.com), and the Port Multiplier will support Sata/150 devices as well.

Although it is possible to route Sata/150 externally, it will be using the same fragile cabling system as for internal devices

Much like USB and FireWire, Port Multiplier also makes it possible to use an external hub for connecting devices - and it can do this in tandem with a standard configuration for external cabling.

A few companies already offer adapters with external ports, notably HighPoint, but this uses the fragile internal connectors and is non-standard. Sata cabling has been widely criticised for its lack of robustness.

Port Multiplier 1.1 uses something called asynchronous notification, which comes from the Digital 1.1 specification. This allows the hub itself to tell the Sata host controller when devices are detached, making hot-swapping more seamless.

But a lot of Sata II enhancements are intended primarily for servers. Not so long ago, network devices such as storage servers used SCSI exclusively but the low cost of Sata disks, plus their higher capacity, has led to quite a few system builders releasing rack devices using Sata instead.

The Port Selector feature in Sata II allows a device to switch between multiple ports. This provides cabling redundancy - if one connection goes down, Port Selector can simply switch to another. Sata II also allows Sata channels to be aggregated into multi-lane pipes to increase bandwidth - again useful for routing from a host adapter to an external hub.

The price differential between Pata and Sata hard disks has fallen to a few pounds, making the barriers to adoption almost zero. However, for the time being the performance benefits apply only in Raid configurations.

In the future, though, it's likely that IBM-PC-compatible systems will start to appear with just one Pata channel intended only for optical disks - as is the case already with Apple PowerMacs.

But, the rationale for retaining Pata will disappear as Sata DVD and CD drives become the norm. That's still far from being the case but Sata DVD writers are now available - Plextor's PX-712SA was one of the first. So using Sata optical writers and readers now is a good way of ensuring these components can be reused in future.

From the smartmon faq: (http://smartmontools.sourceforge.net/#FAQ)

"Smartmontools should work correctly with SATA drives under both Linux 2.4 and 2.6 kernels, /if/ you use the standard IDE drivers in drivers/ide. If you use the new libata drivers, it won't work correctly because libata doesn't yet support the needed ATA-passthrough ioctl() calls. Jeff Garzik, the libata developer, says that this support will be added to libata in the future. When this happens, we'll add support to smartmontools for a new SATA/libata device type '-d sata'. Typically, to force an SATA disk to run using the standard (non-libata) drivers, you must use the BIOS to select "legacy mode" for the controller. If the IDE driver doesn't support your particular SATA controller, or the controller doesn't have a legacy interface, then only libata can be used. Unless the hard disk controller on the system motherboard is Intel, VIA or nVidia, standard IDE drivers may not work."

Note: an unofficial patch to libata that allows smartmontools to be used with the standard '-d ata' device type was posted to the linux kernel mailing list at the end of August 2004. The patch is included in the libata-dev patchset that can be applied to a recent Linux kernel (>= 2.6.9). With a SATA disk driven by a libata driver, smartmontools can now be used by specifying both the device type 'ata' and the SCSI device corresponding to this disk, for example, smartctl -i -d ata /dev/sda. The patch is still under development and it is probably best to make sure that the disk is idle before trying smartmontools.

Google is friend. I was missing the "-d ata" part in the command.

documented on: 2007.07.29

http://linuxmafia.com/faq/Hardware/sata.html

Problem: Serial ATA (also known as S-ATA or SATA) chipsets are rapidly replacing legacy "parallel ATA" (PATA, i.e., regular ATA/133) chipsets - - but many Linux installers' kernels don't yet support many Serial ATA chipsets. If yours isn't supported, you have an installation obstacle. SuSE's, Fedora Core 2's, Gentoo's, Knoppix's, Debian-sarge release candidates, and Mandrakelinux's installation kernels have a good selection of the required drivers. Scott Kveton's Debian netinst image does, likewise, see Links/Resources.

Note: There is no such thing as a distribution or its installer (generically) "having SATA support" (or not). Please send anyone speaking in such terms to this page. (Some SATA chipsets have been supported since practically forever, as their programming interfaces are unchanged from PATA predecessors. Others are brand-new and require new drivers from scratch.)

There are three workaround options:

Linux kernels have two ATA ("IDE") driver sets:

Hardware RAID cards have drivers outside these two collections (e.g., 3w- xxxx, 3w-9xxx, aacraid, cciss, dac960, dpt i2o, gdth, ips, megaraid, megaraid2, mpt*).

(Caveats: Don't assume this page's data are perfect. Also, if a card's price makes it seem too good to be true, it probably is.)

Most ATA RAID host adapters (except 3Ware Escalade, Adaptec 24x0, Areca, HP/ Compaq, IBM ServeRAID, Intel SRC*/ICP Vortex, LSI Logic MegaRAID 150-4/150- 6, and Tekram) turn out, upon examination, to not be real hardware RAID, but rather software/BIOS-dependent fakeraid. (I.e., missing hardware functionality is traditionally emulated inside idiosyncratic, undocumented, and proprietary software drivers, to hit low price points). Fakeraid is difficult to support in Linux — absent either reverse-engineering, special proprietary drivers, or (rare) manufacturer cooperation. (HighPoint, LSI Logic, Nvidia, Promise, and VIA provide proprietary drivers to support their respective fakeraids. I personally would steer clear.)

Linux often cannot read existing fakeraid volumes on such host adapters, unless you're willing to use proprietary fakeraid drivers (where available). But unless you're dual-booting MS-Windows, you shouldn't care, because Linux's software RAID (kernel "md" driver) is much faster and more reliable. You're advised to blow away fakeraid volumes, use SATA drives as straight block devices, and enable Linux software RAID instead, during Linux installation.

Kernel coders are slowly figuring out some fakeraid variants, and coding ataraid/dmraid modules.

Be aware that if any one drive of your SATA-based RAID array goes offline for any reason, including a significant string of media errors, depending on the SATA host adapter, the array may hang and need to be rebooted. This is because many SATA host adapters, like ATA generally absent special hardware provisions, simply don't support hotplug functionality.

This is known to be true, in particular, of Intel's ICH5/ICH5R series, and Garzik has pointed out that that chip series, plus Intel ICH6 (in non-AHCI mode), Pacific Digital Talon, and Promise SATA SX4 — at minimum — will never support hotplug.

If your installer finds no block devices or has other problems, please realise that all Linux SATA support is still (2004-01) hit or miss. (Users of 3Ware cards should have no problems, though. Those with Intel ICH5 chipset may be OK with the 2.4.22 or later drivers/ide piix driver, as that chipset is very nearly identical to prior Intel chips in the PIIX series.) Your best option is to find or build an installer with a recent version of libata, either by virtue of its inclusion in stock 2.6.x kernels, its merger into 2.4.27 and later, or by your applying it as a patch to a (pre-2.4.27) 2.4 installation kernel.

http://linux.yyz.us/sata/software-status.html

July 15, 2005

This status report applies to the latest SATA driver release, found in kernels 2.4.31-preX and 2.6.13-rcX.

Table of Contents

documented on: 2005.07.31

Just for the record:

It turns out to be that I did not set the option (CONFIG_BLK_DEV_SD) in the kernel under Device Drivers —> SCSI device support —> SCSI disk support. I compiled the new 2.6.11 kernel with this option on and everything is running smoothly. Now I have /dev/sda and sdb. I guess the title of the option is a little bit confusing and it would be great if it included something about sata disks too. The only tip I got was the help text for the CONFIG_BLK_DEV_IDE_SATA option, which is not even in the same category!

Ibrahim Mubarak