TR Forums

So the problem starts off when I realize that Diskpart and Disk Management are showing me a drive order wholly different than the physical layout attached to the SATA ports.

The WD Black is physically on SATA 0.
The M4 is physically on SATA 1.

Inside the BIOS configuration the above listed order is confirmed. As the above picture illustrates, Windows is reporting an inverse value. SATA 1 has become Disk 0 and SATA 0 has become Disk 1.

A quick check of my laptop (ICH8 vs the ICH10) shows an identical behavior. The physical SATA port layout and the disk enumeration per Windows don't match. Not serious, not even problematic, but it tweaks at the OCD monster in me.

Lo and behold this behavior is apparently so common that it warranted a KnowledgeBase Article.



So I proceed to dig a little deeper into the configuration of the disk array in Device Manager and find that the corresponding SATA ports also have wholly incorrect DMA/throughput values.

SATA 0 is reporting that it is running in Multi-word DMA 2. A very old DMA mode that is limited to 16.6MB/s.
SATA 1 is reporting that it is running in PIO 4. The checkmark used to enable DMA on the device in Windows is cleared. PIO 4 has a throughput of 16.6MB/s, but unlike MW-DMA dumps all the I/O work onto the CPU.

The system has felt responsive, but at this point I'm figuring I must be blind. As the results being reported imply that disk performance is in ruins.

I try applying the checkmark. The mark fills the box and hitting okay closes out the dialog, but upon opening the applet again I see the checkbox is once again cleared. I try uninstalling both the SATA controller and the disk drive, rebooting, and letting WIndows detect hardware once again. I return to Device Manager only to find the checkbox still cleared and PIO 4 still reported.

Thing is I really should be feeling the fact that my C: drive is in PIO. The boot process and the overall interaction with the system is just entirely too smooth for the sort of performance degredation that should be happening.

So I decide to benchmark the situation.



Yeah. Not MW-DMA 2 and not PIO 4. So is it Windows or the Firmware?

Off to Google where I find I'm not alone in experiencing this behavior. It appears on other brand motherboards and operating systems. Using higher numbered ports (e.g. SATA 3) makes the problem entirely disappear. I'm guessing the storage controller firmware in the ICH is responsible for this entertaining quirk.

TLDR:

1. Being meticulous about which SATA ports you plug your drives into won't pan out like you think.
2. You can't trust the DMA status reported by Windows.
3. Bleh.

I've seen similar things with AMD chipsets on Linux, so yes it is apparently a very common issue, and not just with Intel or Windows. The order in which drives get enumerated by the OS (/dev/sda, /dev/sdb, etc.) often does not match the numbering of the ports on the motherboard.

Since Linux file systems generally get mounted by volume label or UUID this isn't much of an issue in practice; but it does mean you need to be extra careful when partitioning and formatting drives (or setting up software RAID arrays) to be *absolutely* certain you're dealing with the correct drive(s). This can get especially confusing when adding a drive causes the device names of the *existing* drives to get shuffled. I should probably get into the habit of recording the serial numbers of the drives as I install them; this would give me a (nearly) foolproof way of identifying drives, since the serial number is associated with the physical drive and does not depend on the file system being formatted (volume labels and UUIDs get written at format time).

JBI, that's a Linux "feature" I could really live without. Historically, we've had two or three different ways of enumerating drives, and they all suck. Windows just adds a drive letter, much easier and less error-prone. For example, a couple months ago I upgraded an OpenSuse box, only to find out it didn't boot afterwards because something (kernel upgrade? module? whatever) shuffled drives around.

morphine wrote:

JBI, that's a Linux "feature" I could really live without. Historically, we've had two or three different ways of enumerating drives, and they all suck. Windows just adds a drive letter, much easier and less error-prone. For example, a couple months ago I upgraded an OpenSuse box, only to find out it didn't boot afterwards because something (kernel upgrade? module? whatever) shuffled drives around.

As I mentioned in the previous post, newer distros (mostly) fix this by relying on UUIDs or volume labels for nearly everything. The only time it still matters is when you really need to deal with the raw underlying device (e.g. partitioning, software RAID setup, low-level diagnostics).

If your /etc/fstab still has device names in it, you (or your distro) are doing something wrong!