disabling libata

disabling libata

[Imre Gergely]

hi

i have a SATA hardisk, and am using FC4 with default kernel
(2.6.14-1.1644_FC4). i was wondering if it's possible to tell the kernel to use
the old ATA driver with SATA support instead of libata, for my harddisk to
appear as hdX, and not sdX.


(please CC the answers, as i'm not on the list)

thank you.

Re: disabling libata

[Erik Mouw]

On Fri, Feb 10, 2006 at 03:40:22PM +0200, Imre Gergely wrote:
> i have a SATA hardisk, and am using FC4 with default kernel
> (2.6.14-1.1644_FC4). i was wondering if it's possible to tell the kernel to use
> the old ATA driver with SATA support instead of libata, for my harddisk to
> appear as hdX, and not sdX.

Why would you want to do that? SATA are driven by libata and the disks
turn up as SCSI devices. There's no way around that (yet).


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

Re: disabling libata

[Imre Gergely]

Erik Mouw wrote:
> On Fri, Feb 10, 2006 at 03:40:22PM +0200, Imre Gergely wrote:
>> i have a SATA hardisk, and am using FC4 with default kernel
>> (2.6.14-1.1644_FC4). i was wondering if it's possible to tell the kernel to use
>> the old ATA driver with SATA support instead of libata, for my harddisk to
>> appear as hdX, and not sdX.
> 
> Why would you want to do that? SATA are driven by libata and the disks
> turn up as SCSI devices. There's no way around that (yet).
> 

if i recompile the kernel, and leave out the libata part, and compile in
support for SATA, under ATA, the harddisks turn up as normal IDE devices (ie
hde, hdf, etc). i would like that without recompiling. if it's possible of course.

Re: disabling libata

[Erik Mouw]

On Fri, Feb 10, 2006 at 04:16:21PM +0200, Imre Gergely wrote:
> Erik Mouw wrote:
> > On Fri, Feb 10, 2006 at 03:40:22PM +0200, Imre Gergely wrote:
> >> i have a SATA hardisk, and am using FC4 with default kernel
> >> (2.6.14-1.1644_FC4). i was wondering if it's possible to tell the kernel to use
> >> the old ATA driver with SATA support instead of libata, for my harddisk to
> >> appear as hdX, and not sdX.
> > 
> > Why would you want to do that? SATA are driven by libata and the disks
> > turn up as SCSI devices. There's no way around that (yet).
> 
> if i recompile the kernel, and leave out the libata part, and compile in
> support for SATA, under ATA, the harddisks turn up as normal IDE devices (ie
> hde, hdf, etc). i would like that without recompiling. if it's possible of course.

Yes, I know that's possible for some SATA adapters, but my question is
why would you want to do that? The SATA support in the IDE subsystem is
deprecated, you should really use libata.


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

Re: disabling libata

[Imre Gergely]

Erik Mouw wrote:
> On Fri, Feb 10, 2006 at 04:16:21PM +0200, Imre Gergely wrote:
>> Erik Mouw wrote:
>>> On Fri, Feb 10, 2006 at 03:40:22PM +0200, Imre Gergely wrote:
>>>> i have a SATA hardisk, and am using FC4 with default kernel
>>>> (2.6.14-1.1644_FC4). i was wondering if it's possible to tell the kernel to use
>>>> the old ATA driver with SATA support instead of libata, for my harddisk to
>>>> appear as hdX, and not sdX.
>>> Why would you want to do that? SATA are driven by libata and the disks
>>> turn up as SCSI devices. There's no way around that (yet).
>> if i recompile the kernel, and leave out the libata part, and compile in
>> support for SATA, under ATA, the harddisks turn up as normal IDE devices (ie
>> hde, hdf, etc). i would like that without recompiling. if it's possible of course.
> 
> Yes, I know that's possible for some SATA adapters, but my question is
> why would you want to do that? The SATA support in the IDE subsystem is
> deprecated, you should really use libata.
> 
> 
> Erik
> 

maybe it's just me... but it looks like if as SCSI device the whole thing is
slower than with IDE. i haven't tested it yet, but as sda the system load is
very high, i did some tests with dd, and the CPU usage is always at 98-100%.
and when i'm copying something to another disk, the other programs barely move,
sometimes even the mouse gets stuck. i dunno where this is coming from. i
thought i try with the old driver.

maybe if you could give me some hints about how to test the whole thing, i
could post some results. i know that driver change isn't the answer, but i
still wanted to know if one can switch between the old and the libata driver
without recompiling (with some boot parameters to the kernel perhaps).

Re: disabling libata

[Alan Cox]

On Gwe, 2006-02-10 at 18:02 +0200, Imre Gergely wrote:
> maybe it's just me... but it looks like if as SCSI device the whole thing is
> slower than with IDE. i haven't tested it yet, but as sda the system load is
> very high, i did some tests with dd, and the CPU usage is always at 98-100%.


Not expected behaviour. Can you provide hardware info and boot up
messages please.

Re: disabling libata

[Imre Gergely]

Alan Cox wrote:
> On Gwe, 2006-02-10 at 18:02 +0200, Imre Gergely wrote:
>> maybe it's just me... but it looks like if as SCSI device the whole thing is
>> slower than with IDE. i haven't tested it yet, but as sda the system load is
>> very high, i did some tests with dd, and the CPU usage is always at 98-100%.
> 
> 
> Not expected behaviour. Can you provide hardware info and boot up
> messages please.
> 
> 

AMD Sempron 2600+, 512MB

00:09.0 IDE interface: nVidia Corporation MCP2A IDE (rev a3)
00:0b.0 IDE interface: nVidia Corporation nForce2 Serial ATA Controller (rev a3)

...
ata1: SATA max UDMA/133 cmd 0x9F0 ctl 0xBF2 bmdma 0xC800 irq 11
ata2: SATA max UDMA/133 cmd 0x970 ctl 0xB72 bmdma 0xC808 irq 11
input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3468 86:3c01 87:4003 88:407f
ata1: dev 0 ATA, max UDMA/133, 312579695 sectors: lba48
nv_sata: Primary device added
nv_sata: Primary device removed
nv_sata: Secondary device removed
ata1: dev 0 configured for UDMA/133
scsi0 : sata_nv
ata2: no device found (phy stat 00000000)
scsi1 : sata_nv
  Vendor: ATA       Model: ST3160023AS       Rev: 3.01
  Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sda: 312579695 512-byte hdwr sectors (160041 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 312579695 512-byte hdwr sectors (160041 MB)
SCSI device sda: drive cache: write back
 sda: sda1 sda2 sda3 sda4
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
kjournald starting.  Commit interval 5 seconds
...

[root@imi ~]# hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   1652 MB in  2.00 seconds = 825.95 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for
device
 Timing buffered disk reads:  146 MB in  3.00 seconds =  48.60 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for
device

[root@imi stuff]# hdparm /dev/sda

/dev/sda:
 IO_support   =  0 (default 16-bit)
 readonly     =  0 (off)
 readahead    = 256 (on)
 geometry     = 19457/255/63, sectors = 160040803840, start = 0

[root@imi stuff]# cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]

(but i tried all schedulers, didn't see any big improvements)

i tried to create an 1gb file like this:

[root@imi stuff]# time dd if=/dev/zero of=./1gbfile bs=512k count=2048
2048+0 records in
2048+0 records out

real    1m6.086s
user    0m0.012s
sys     0m5.920s

vmstat output lookes like this:


[root@imi ~]# vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 1  0    112  94208   1416  96616    0    0   762   427  933  3359 15  4 69 12
 2  3    112   5076    808 180052    0    0    28 71260  768  3001  3 55 42  0
 0  3    112   7060    820 178608    0    0     8 20500  632  2596  1  5  0 94
 4  3    112   9292    820 178612    0    0     4     0  606  2695  1  1  0 98
 0  2    112   6340    876 181740    0    0    16 22440  608  2689  1 49  0 50
 0  2    112   5964    888 179848    0    0    20 54188  589  2761  5 25  0 70
 0  2    112   7580    904 179900    0    0    40     0  583  2603  1  1  0 98
 1  3    112   4956    932 182972    0    0    40 27404  622  2635  3 16  0 81
 0  6    112   4952    952 182772    0    0    28  4000  664  2775  1 26  0 73

i read somewhere about some tests, SATA vs IDE, and they were talking about a
constant 10-13% CPU usage, nothing more.

Re: disabling libata

[Wakko Warner]

Imre Gergely wrote:
> 
> 
> Erik Mouw wrote:
> > Yes, I know that's possible for some SATA adapters, but my question is
> > why would you want to do that? The SATA support in the IDE subsystem is
> > deprecated, you should really use libata.
> > 
> > 
> > Erik
> > 
> 
> maybe it's just me... but it looks like if as SCSI device the whole thing is
> slower than with IDE. i haven't tested it yet, but as sda the system load is
> very high, i did some tests with dd, and the CPU usage is always at 98-100%.
> and when i'm copying something to another disk, the other programs barely move,
> sometimes even the mouse gets stuck. i dunno where this is coming from. i
> thought i try with the old driver.

I asked this same question with U320 scsi controller.  I noticed my CPU went
to 100%.  It never really was being used at all, just in wait.  Run top to
see if "wa" is high or not.

This is what I see (no load, no disk activity) for the CPU:
Cpu(s):  0.1% us,  0.1% sy,  0.0% ni, 97.6% id,  2.2% wa,  0.0% hi,  0.1% si

Copying a single disk to /dev/null (9.1gb):
Cpu(s):  0.0% us,  1.7% sy,  0.0% ni, 74.8% id, 23.3% wa,  0.0% hi,  0.2% si

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
 Got Gas???

Re: disabling libata

[Barry K. Nathan]

On 2/10/06, Erik Mouw <erik@harddisk-recovery.com> wrote:
> Why would you want to do that? SATA are driven by libata and the disks
> turn up as SCSI devices. There's no way around that (yet).

"Yet"? I haven't been following things closely enough, but I got the
impression that the long-term plan was something like this:

1. Move all the IDE drivers over to libata (Alan Cox has a patch to do
this, at least part of that patch is in -mm, and I'm already running
this flawlessly on one of my systems -- it's not debugged yet, but
none of the bugs happen to hit me). Yes, this means *all* ATA hard
drives become /dev/sd*, not just SATA.

2. Reorganize the Kconfig menus so that ATA stuff is no longer a
subsection of SCSI.

3. Rename /dev/sd* to /dev/disk*.

Of course, I could be mistaken (in which case, please feel free to correct me).
--
-Barry K. Nathan <barryn@pobox.com>