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.
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 -- http://www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
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.
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 -- http://www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
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).
On 2/10/06, Erik Mouw <[email protected]> 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 <[email protected]>
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.
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???
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.