[9fans] Any one going to change to sata disks?

[9fans] Any one going to change to sata disks?

[Francisco J Ballesteros]

We are changing our file server, and this time we had
a bit of luck and the new 500G ata disk worked with
one of the bios.

But next time I think we´ll have to write a driver for sata
if nobody else has done it before.

The question is, is someone doing such thing?
I know it works w/o dma, as said here time ago, but
I don´t think that suffices.

thanks

Re: [9fans] Any one going to change to sata disks?

[Brantley Coile]

PIO for sata is RRRREEEEAAAALLLLLYYYYY SSSSSLLLLLOOOOOOWWWWW.
Geoff is working on Marvell drivers for us at Coraid.
I've already said that his work can be sent back to
sources.

This works for Marvell 88SX[56]0[48][01] intervaces.
You can get PCI-X cards with these on them.

> We are changing our file server, and this time we had
> a bit of luck and the new 500G ata disk worked with
> one of the bios.
> 
> But next time I think we´ll have to write a driver for sata
> if nobody else has done it before.
> 
> The question is, is someone doing such thing?
> I know it works w/o dma, as said here time ago, but
> I don´t think that suffices.
> 
> thanks

Re: [9fans] Any one going to change to sata disks?

[jmk]

I admit to winging this. The only real problem as far as I know
with SATA drives is, just like with parallel ATA drives, if you
don't know how to programme the controller to do DMA then you can't
use DMA. If the controller implements the same DMA scheme as some
existing ATA controller then, since the BIOS will set up the PHY
just like it will set up the ATA operating modes, then DMA works OK.

devi% pci|grep disk
0.15.0:	disk 01.04.00 1106/3149  11 0:0000b401 16 1:0000b801 16 2:0000bc01 16 3:0000c001 16 4:0000c401 16 5:0000c801 256
0.15.1:	disk 01.01.8a 1106/0571 255 4:0000cc01 16
devi% cat /dev/sdC0/ctl
inquiry ST380013AS                              
config 0C5A capabilities 2F00 dma 00550040 dmactl 00000000 rwm 16 rwmctl 0 lba48always off
geometry 156301488 512 16383 16 63
part data 0 156301488
part plan9 63 156296385
part 9fat 63 204863
part fs 204863 153150657
part swap 153150657 154199233
part cache 154199233 156296385
devi% time dd </dev/sdC0/data -bs 64k -count 1024 | md5sum
1024+0 records in
1024+0 records out
0.00u 0.11s 20.37r 	 dd -bs 64k -count 1024 ...
433e70fbe1b5e7b5b1c31f4b436ffcc8
devi% echo dma on>/dev/sdC0/ctl
devi% time dd </dev/sdC0/data -bs 64k -count 1024 | md5sum
1024+0 records in
1024+0 records out
0.00u 0.11s 2.75r 	 dd -bs 64k -count 1024 ...
433e70fbe1b5e7b5b1c31f4b436ffcc8
devi% 

Of course, there are bugs in the chips, just as always, so
your mileage may vary.


On Thu Jun 29 15:22:26 EDT 2006, brantley@coraid.com wrote:
> PIO for sata is RRRREEEEAAAALLLLLYYYYY SSSSSLLLLLOOOOOOWWWWW.
> Geoff is working on Marvell drivers for us at Coraid.
> I've already said that his work can be sent back to
> sources.
> 
> This works for Marvell 88SX[56]0[48][01] intervaces.
> You can get PCI-X cards with these on them.
> 
> > We are changing our file server, and this time we had
> > a bit of luck and the new 500G ata disk worked with
> > one of the bios.
> > 
> > But next time I think we´ll have to write a driver for sata
> > if nobody else has done it before.
> > 
> > The question is, is someone doing such thing?
> > I know it works w/o dma, as said here time ago, but
> > I don´t think that suffices.
> > 
> > thanks

Re: Re: [9fans] Any one going to change to sata disks?

[andrey mirtchovski]

here's my recent experience with sata:

i had two disks i wanted to use, big 250gb chunks of hunk. if one was
plugged in by itself it will appear as sdC0, if i plugged in a second
one none of the two will be recognized, not even to boot from. one had
to keep switching them from one slot to the other and fiddling with
the bios just to get them both to be visible to the os. if anything
was plugged in to the IDE slots, including just a cdrom, the sata
disks (or one disk, rather) would be delegated to sdE0...

with two sata disks plugged in as sdC0 and sdD0, the bandwidth to one
would be 5 times slower than the bandwidth to the other. same test as
jmk's would complete in 2-3 seconds on sdC0, and 11-12 seconds on
sdD0...

Re: Re: [9fans] Any one going to change to sata disks?

[jmk]

Gosh, that sounds too hard to get right.
Let's just go to the Linux Mall and shop.
I mean, after all they've, like, got all
that stuff just sitting there on the shelves,
you don't even need to assemble it (IKEA
sucks! What's that all about?) never mind
know how it works. Just use your mom's
credit card and, like, PLUG IT IN!

Barbie

On Thu Jun 29 17:04:23 EDT 2006, mirtchovski@gmail.com wrote:
> here's my recent experience with sata:
> 
> i had two disks i wanted to use, big 250gb chunks of hunk. if one was
> plugged in by itself it will appear as sdC0, if i plugged in a second
> one none of the two will be recognized, not even to boot from. one had
> to keep switching them from one slot to the other and fiddling with
> the bios just to get them both to be visible to the os. if anything
> was plugged in to the IDE slots, including just a cdrom, the sata
> disks (or one disk, rather) would be delegated to sdE0...
> 
> with two sata disks plugged in as sdC0 and sdD0, the bandwidth to one
> would be 5 times slower than the bandwidth to the other. same test as
> jmk's would complete in 2-3 seconds on sdC0, and 11-12 seconds on
> sdD0...

Re: [9fans] Any one going to change to sata disks?

[Ronald G Minnich]

jmk@plan9.bell-labs.com wrote:
> Gosh, that sounds too hard to get right.
> Let's just go to the Linux Mall and shop.
> I mean, after all they've, like, got all
> that stuff just sitting there on the shelves,
> you don't even need to assemble it (IKEA
> sucks! What's that all about?) never mind
> know how it works. Just use your mom's
> credit card and, like, PLUG IT IN!


actually, it would have been fine, but they asked Barbie to write a 
driver. At that point, well, hurl! She'd rather do a powerpoint 
presentation on Xen than write a driver.

ron

Re: Re: [9fans] Any one going to change to sata disks?

[geoff]

[-- Attachment #1: Type: text/plain, Size: 129 bytes --]

Andrey, are you using a Marvell controller, or one that looks to
software like an IDE/(P)ATA controller (e.g., Silicon Image)?

[-- Attachment #2: Type: message/rfc822, Size: 3884 bytes --]

From: "andrey mirtchovski" <mirtchovski@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: Re: [9fans] Any one going to change to sata disks?
Date: Thu, 29 Jun 2006 15:03:36 -0600
Message-ID: <14ec7b180606291403n66dbbc02y242600363e47c5dc@mail.gmail.com>

here's my recent experience with sata:

i had two disks i wanted to use, big 250gb chunks of hunk. if one was
plugged in by itself it will appear as sdC0, if i plugged in a second
one none of the two will be recognized, not even to boot from. one had
to keep switching them from one slot to the other and fiddling with
the bios just to get them both to be visible to the os. if anything
was plugged in to the IDE slots, including just a cdrom, the sata
disks (or one disk, rather) would be delegated to sdE0...

with two sata disks plugged in as sdC0 and sdD0, the bandwidth to one
would be 5 times slower than the bandwidth to the other. same test as
jmk's would complete in 2-3 seconds on sdC0, and 11-12 seconds on
sdD0...

Re: Re: Re: [9fans] Any one going to change to sata disks?

[andrey mirtchovski]

it's a  /* SiI 3114 SATA/RAID */

1.11.0:	disk 01.80.00 1095/3114   9 0:00009c01 16 1:00009801 16
2:00009401 16 3:00009001 16 4:00008c01 16 5:ee7f9c00 1024


On 6/29/06, geoff@collyer.net <geoff@collyer.net> wrote:
> Andrey, are you using a Marvell controller, or one that looks to
> software like an IDE/(P)ATA controller (e.g., Silicon Image)?
>

Re: Re: [9fans] Any one going to change to sata disks?

[Francisco J Ballesteros]

Amazing. Similar story here. We ended up with one sata disk as sdC0
and one ata (500G) disk as sdD0. If we plug in anything else (including cd)
the bios hangs.

On 6/29/06, andrey mirtchovski <mirtchovski@gmail.com> wrote:
> here's my recent experience with sata:
>
> i had two disks i wanted to use, big 250gb chunks of hunk. if one was
> plugged in by itself it will appear as sdC0, if i plugged in a second
> one none of the two will be recognized, not even to boot from. one had
> to keep switching them from one slot to the other and fiddling with
> the bios just to get them both to be visible to the os. if anything
> was plugged in to the IDE slots, including just a cdrom, the sata
> disks (or one disk, rather) would be delegated to sdE0...
>
> with two sata disks plugged in as sdC0 and sdD0, the bandwidth to one
> would be 5 times slower than the bandwidth to the other. same test as
> jmk's would complete in 2-3 seconds on sdC0, and 11-12 seconds on
> sdD0...
>
>

Re: [9fans] Any one going to change to sata disks?

[Ronald G Minnich]

Francisco J Ballesteros wrote:
> Amazing. Similar story here. We ended up with one sata disk as sdC0
> and one ata (500G) disk as sdD0. If we plug in anything else (including cd)
> the bios hangs.

this is not exactly a shock, that the hardware dudes + committee 
designed a fairly complex "thing", and nobody realized until it was too 
late that the "thing" was going to make the bios a mess, and require a 
bunch of bug-ridden drivers to be jammed into the bios to make it all go.

It's just USB all over again. It's quite amazing to watch the factory 
BIOS on the various platforms struggle -- and fail, most of the time -- 
to work with pretty standard USB hardware; and to watch Linux just sort 
of configure it up and work. (oops, I said something good about Linux; 
am I going to get tossed off the list?)

It would be really cool, with all these new standards, to get some 
sanity in the process, i.e. it would have been nice had the hardware 
guys somehow been in the same room as the comittee, and maybe a few 
software guys sprinkled in just for the heck of it.
ACPI
USB
IPMI 2.0
SATA
Infiniband

There seems to be a new item in this list once per year.

A quarter-century later, ethernet continues to amaze. It started out at 
3 mbits, is now at 10 gbits, and somehow it all works, and it can be 
programmed at low levels without inordinate pain. Probably, in large 
part, because it didn't promise too much, and hence did not require too 
much. And, it was designed by a couple of smart guys, not a comittee of 
vendors working on "value adds" and "lock in".

ron

Re: [9fans] Any one going to change to sata disks?

[Brantley Coile]

> A quarter-century later, ethernet continues to amaze. It started out at 
> 3 mbits, is now at 10 gbits, and somehow it all works, and it can be 
> programmed at low levels without inordinate pain. Probably, in large 
> part, because it didn't promise too much, and hence did not require too 
> much. And, it was designed by a couple of smart guys, not a comittee of 
> vendors working on "value adds" and "lock in".

The power of simplicity.

Re: [9fans] Any one going to change to sata disks?

[quanstro]

ethernet could have been a failure for many non-technical reasons.
it just happened to be at the right place at the right time.  and when
problems like collisions (remember 10base(2|5)?) good solutions like
switching hubs were possible.

as for speed, that's the power of new-fangled noise reduction.

- erik

On Fri Jun 30 09:03:26 CDT 2006, brantley@coraid.com wrote:
> > A quarter-century later, ethernet continues to amaze. It started out at 
> > 3 mbits, is now at 10 gbits, and somehow it all works, and it can be 
> > programmed at low levels without inordinate pain. Probably, in large 
> > part, because it didn't promise too much, and hence did not require too 
> > much. And, it was designed by a couple of smart guys, not a comittee of 
> > vendors working on "value adds" and "lock in".
> 
> The power of simplicity.

Re: [9fans] Any one going to change to sata disks?

[Brantley Coile]

> ethernet could have been a failure for many non-technical reasons.
> it just happened to be at the right place at the right time.  and when
> problems like collisions (remember 10base(2|5)?) good solutions like
> switching hubs were possible.

Back in the mid 1980's I was going to try to get the company I worked
for to use Datakit instead of Ethernet, but when I saw the $100K price
tag, I gave up.

It took a little while for hubs to be cheap enough to replace the yellow snake.

Re: [9fans] Any one going to change to sata disks?

[quanstro]

wow!  that's pricy.

for 100k you could have had the same style solution in ethernet by buying 
fancy routers, even in those days.

wasn't one of the advantages of dk supposed to be that it was cheep to
implement?

- erik

On Fri Jun 30 09:32:39 CDT 2006, brantley@coraid.com wrote:
> 
> Back in the mid 1980's I was going to try to get the company I worked
> for to use Datakit instead of Ethernet, but when I saw the $100K price
> tag, I gave up.
> 
> It took a little while for hubs to be cheap enough to replace the yellow snake.

Re: [9fans] Any one going to change to sata disks?

[Brantley Coile]

These were the days before switches and hubs, just yellow snake
and $1,000 interface boards.  This would have been 1986 or so.

I was always frustrated that the ideas from the Labs never made it
outside the building intact.  The Blit turned into the DMD5620 with a
$6,000 price tag in the days of $1,000 terminals, the 3B20 costs more
than a VAX but ran slower, streams turned into STREAMS.  It was like
there was some sort of screw-it-up filter at Basking Ridge.  Good
ideas went in and bad products, bad marketing, bad pricing would
emerge.

But I guess that's just the down side of working for the phone
company.  The up side was all those resources to pursue really neat
ideas in the first place.  Bell Labs changed the world.  A bunch.


> wow!  that's pricy.
> 
> for 100k you could have had the same style solution in ethernet by buying 
> fancy routers, even in those days.
> 
> wasn't one of the advantages of dk supposed to be that it was cheep to
> implement?
> 
> - erik
> 
> On Fri Jun 30 09:32:39 CDT 2006, brantley@coraid.com wrote:
>> 
>> Back in the mid 1980's I was going to try to get the company I worked
>> for to use Datakit instead of Ethernet, but when I saw the $100K price
>> tag, I gave up.
>> 
>> It took a little while for hubs to be cheap enough to replace the yellow snake.

Re: Re: [9fans] Any one going to change to sata disks?

[Jack Johnson]

On 6/29/06, Francisco J Ballesteros <nemo@lsub.org> wrote:
> Amazing. Similar story here. We ended up with one sata disk as sdC0
> and one ata (500G) disk as sdD0. If we plug in anything else (including cd)
> the bios hangs.

Has anyone looked at the 3ware controllers, instead of supporting the
random chipsets on the various motherboards?

http://www.3ware.com/products/index.asp

They act like SCSI controllers, which might return some of the sanity,
and hardware RAID is always nice.  Plus, plenty of open source driver
implementations.

No idea on the quality of the source, but performance under Linux is
good. I usually use  RAID 10, but I think it's StorageReview that has
a fair review that notes pretty good RAID 5 performance:

http://www.storagereview.com/articles/200111/20011119Escalade7450_1.html

Two-port cards start around $140 or so -- about an order of magnitude
more than the competition -- but definitely with the 4-port cards and
up I've found the price to be worth it.

-Jack

----------------

http://www.3ware.com/kb/attachments/FreeBSD6_driver_source_9550SX-GUID1e41dd6deab5404fac46976c7e166c33.zip

----------------

twa driver

URL: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/twa/
URL: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/modules/twa/

Contact: Vinod Kashyap <vkashyap at amcc.com>

A newly re-architected twa(4) driver was committed to 6 -CURRENT on
04/12/2005. Highlights of this release are:
1. The driver has been re-architected to use a "Common Layer" (all
tw_cl* files), which is a consolidation of all OS-independent parts of
the driver. The FreeBSD OS specific portions of the driver go into an
"OS Layer" (all tw_osl* files). This re-architecture is to achieve
better maintainability, consistency of behavior across OS's, and
better portability to new OS's (drivers for new OS's can be written by
just adding an OS Layer that's specific to the OS, by complying to a
"Common Layer Programming Interface (CLPI)" API. If there's interest
in porting the 3ware driver to any other OS, you may contact ctchu at
amcc.com to get a copy of the CLPI specifications.
2. The driver takes advantage of multiple processors. It does not need
to be Giant protected anymore.
3. The driver has a new firmware image bundled, the new features of
which include Online Capacity Expansion and multi-lun support, among
others. More details about 3ware's 9.2 release can be found here:
http://www.3ware.com/download/Escalade9000Series/9.2/9.2_Release_Notes_Web.pdf

( from http://kerneltrap.org/node/5035 )

----------------

Re: Re: [9fans] Any one going to change to sata disks?

[jmk]

On Thu Jun 29 20:18:05 EDT 2006, knapjack@gmail.com wrote:
> ...
> 2. The driver takes advantage of multiple processors. It does not need
> to be Giant protected anymore.
> ...

i thought this was a humourous signature containing
a candidate for the fortunes file until i saw the later
references to 3ware.com.

Re: Re: [9fans] Any one going to change to sata disks?

[geoff]

[-- Attachment #1: Type: text/plain, Size: 2656 bytes --]

Some of us have considered the 3ware cards in the past (see the
archives).  Their drivers are enormous, and I don't know if that's
because the cards are inherently complex or if they just can't write
decent drivers.  I don't see any documentation for device-driver
writers on their web site; that would help to answer the question.
Here's the FreeBSD 6 driver you cited:

; wc -l *.[ch]
     442 tw_cl.h
     214 tw_cl_externs.h
     452 tw_cl_fwif.h
   47792 tw_cl_fwimg.c
    1238 tw_cl_init.c
     831 tw_cl_intr.c
    1490 tw_cl_io.c
     111 tw_cl_ioctl.h
    1091 tw_cl_misc.c
     662 tw_cl_share.h
     319 tw_osl.h
     801 tw_osl_cam.c
      95 tw_osl_externs.h
    1769 tw_osl_freebsd.c
      79 tw_osl_includes.h
     365 tw_osl_inline.h
     115 tw_osl_ioctl.h
     117 tw_osl_share.h
      63 tw_osl_types.h
   58046 total

Even omitting the firmware image (tw_cl_fwimg.c), which is also vast,
that's over 10,000 lines of C for a disk driver, 4,223 lines of which
is the `OS Layer' (tw_osl_*).  Our largest Plan 9 driver (other than
devsdp.c), which is also one of the largest source files, is
pc/sd53c8xx.c, which weighs in at 2,264 lines.  I think *that's* huge,
but apparently the NCR controllers are messy.  Maybe it's possible to
`just' write an `OS Layer' for the twa driver, but do we really want
to include a driver that's as big as a V6 Unix kernel (`free Unix
kernel with every Plan 9 distribution')?

; cd v6/usr/sys
; wc -l *.h */*.[ch]
     77 buf.h
     55 conf.h
     19 file.h
     26 filsys.h
     31 ino.h
     47 inode.h
     91 param.h
     42 proc.h
     16 reg.h
     26 seg.h
     54 systm.h
     15 text.h
     84 tty.h
     93 user.h
    540 conf/mkconf.c
    146 conf/sysfix.c
    636 dmr/bio.c
     70 dmr/cat.c
    231 dmr/dc.c
    300 dmr/dh.c
     88 dmr/dhdm.c
     23 dmr/dhfdm.c
     89 dmr/dn.c
    255 dmr/dp.c
    218 dmr/hp.c
    116 dmr/hs.c
    248 dmr/ht.c
    117 dmr/kl.c
    184 dmr/lp.c
     70 dmr/mem.c
     21 dmr/partab.c
    166 dmr/pc.c
    103 dmr/rf.c
    132 dmr/rk.c
    174 dmr/rp.c
     54 dmr/sys.c
    171 dmr/tc.c
    221 dmr/tm.c
    537 dmr/tty.c
    122 dmr/vs.c
     70 dmr/vt.c
    314 ken/alloc.c
    173 ken/clock.c
    258 ken/fio.c
    234 ken/iget.c
    266 ken/main.c
     87 ken/malloc.c
    200 ken/nami.c
    222 ken/pipe.c
    150 ken/prf.c
    195 ken/rdwri.c
    374 ken/sig.c
    490 ken/slp.c
    207 ken/subr.c
    407 ken/sys1.c
    289 ken/sys2.c
    194 ken/sys3.c
    259 ken/sys4.c
     77 ken/sysent.c
    156 ken/text.c
    212 ken/trap.c
  10542 total

[-- Attachment #2: Type: message/rfc822, Size: 5887 bytes --]

From: "Jack Johnson" <knapjack@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: Re: [9fans] Any one going to change to sata disks?
Date: Thu, 29 Jun 2006 17:17:45 -0700
Message-ID: <6e35c0620606291717l27fcc02atfcaac140a7cf19ff@mail.gmail.com>

On 6/29/06, Francisco J Ballesteros <nemo@lsub.org> wrote:
> Amazing. Similar story here. We ended up with one sata disk as sdC0
> and one ata (500G) disk as sdD0. If we plug in anything else (including cd)
> the bios hangs.

Has anyone looked at the 3ware controllers, instead of supporting the
random chipsets on the various motherboards?

http://www.3ware.com/products/index.asp

They act like SCSI controllers, which might return some of the sanity,
and hardware RAID is always nice.  Plus, plenty of open source driver
implementations.

No idea on the quality of the source, but performance under Linux is
good. I usually use  RAID 10, but I think it's StorageReview that has
a fair review that notes pretty good RAID 5 performance:

http://www.storagereview.com/articles/200111/20011119Escalade7450_1.html

Two-port cards start around $140 or so -- about an order of magnitude
more than the competition -- but definitely with the 4-port cards and
up I've found the price to be worth it.

-Jack

----------------

http://www.3ware.com/kb/attachments/FreeBSD6_driver_source_9550SX-GUID1e41dd6deab5404fac46976c7e166c33.zip

----------------

twa driver

URL: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/twa/
URL: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/modules/twa/

Contact: Vinod Kashyap <vkashyap at amcc.com>

A newly re-architected twa(4) driver was committed to 6 -CURRENT on
04/12/2005. Highlights of this release are:
1. The driver has been re-architected to use a "Common Layer" (all
tw_cl* files), which is a consolidation of all OS-independent parts of
the driver. The FreeBSD OS specific portions of the driver go into an
"OS Layer" (all tw_osl* files). This re-architecture is to achieve
better maintainability, consistency of behavior across OS's, and
better portability to new OS's (drivers for new OS's can be written by
just adding an OS Layer that's specific to the OS, by complying to a
"Common Layer Programming Interface (CLPI)" API. If there's interest
in porting the 3ware driver to any other OS, you may contact ctchu at
amcc.com to get a copy of the CLPI specifications.
2. The driver takes advantage of multiple processors. It does not need
to be Giant protected anymore.
3. The driver has a new firmware image bundled, the new features of
which include Online Capacity Expansion and multi-lun support, among
others. More details about 3ware's 9.2 release can be found here:
http://www.3ware.com/download/Escalade9000Series/9.2/9.2_Release_Notes_Web.pdf

( from http://kerneltrap.org/node/5035 )

----------------

Re: Re: [9fans] Any one going to change to sata disks?

[Jack Johnson]

On 6/29/06, geoff@collyer.net <geoff@collyer.net> wrote:
> Even omitting the firmware image (tw_cl_fwimg.c), which is also vast,
> that's over 10,000 lines of C for a disk driver, 4,223 lines of which
> is the `OS Layer' (tw_osl_*).  Our largest Plan 9 driver (other than
> devsdp.c), which is also one of the largest source files, is
> pc/sd53c8xx.c, which weighs in at 2,264 lines.  I think *that's* huge,
> but apparently the NCR controllers are messy.  Maybe it's possible to
> `just' write an `OS Layer' for the twa driver, but do we really want
> to include a driver that's as big as a V6 Unix kernel (`free Unix
> kernel with every Plan 9 distribution')?

Good point.  Strike one. :)

How about the LSIs?  This looks promising:

( from http://linuxmafia.com/faq/Hardware/sata.html#lsilogic )

"LSI Logic MegaRAID SATA 150-4 (four ports) and 150-6 (six ports)
Serial ATA RAID Host Adapters — real hardware RAID. Work with 2.4.x
kernel's megaraid2 driver (same one as for SCSI). Cards use an Intel
GC80302 dedicated I/O processor. This chipset, under its former AMI
brand name, has had a long and excellent history with SCSI gear.
Optional battery backup unit is available for the model 150-6 card's
cache, for more reliable operation in the event of power loss, etc.
These cards should not be confused with the low-end LSI Logic MegaRaid
SATA 150-2 card."

Skimming for source now to do the same size comparison....

-Jack

Re: Re: [9fans] Any one going to change to sata disks?

[Jack Johnson]

On 6/30/06, Jack Johnson <knapjack@gmail.com> wrote:
> Skimming for source now to do the same size comparison....

Looks like src/sys/dev/amr/ if anyone has a FreeBSD kernel tree handy....

-Jack

Re: Re: [9fans] Any one going to change to sata disks?

[jmk]

I had to go back and read the thread to see how we got here:

	1) some piece of hardware which no real effort has been made
       to programme doesn't work right;
	2) familiar discussion about hardware, drivers, documentation;
	3) suggestion is to buy a much more expensive piece of
	   hardware with similar lack of documentation.

We haven't invested any effort in making the free hardware we
get on almost every motherboard work, maybe someone should try.

I think we need to focus here.

On Fri Jun 30 12:10:12 EDT 2006, knapjack@gmail.com wrote:
> On 6/29/06, geoff@collyer.net <geoff@collyer.net> wrote:
> > Even omitting the firmware image (tw_cl_fwimg.c), which is also vast,
> > that's over 10,000 lines of C for a disk driver, 4,223 lines of which
> > is the `OS Layer' (tw_osl_*).  Our largest Plan 9 driver (other than
> > devsdp.c), which is also one of the largest source files, is
> > pc/sd53c8xx.c, which weighs in at 2,264 lines.  I think *that's* huge,
> > but apparently the NCR controllers are messy.  Maybe it's possible to
> > `just' write an `OS Layer' for the twa driver, but do we really want
> > to include a driver that's as big as a V6 Unix kernel (`free Unix
> > kernel with every Plan 9 distribution')?
> 
> Good point.  Strike one. :)
> 
> How about the LSIs?  This looks promising:
> 
> ( from http://linuxmafia.com/faq/Hardware/sata.html#lsilogic )
> 
> "LSI Logic MegaRAID SATA 150-4 (four ports) and 150-6 (six ports)
> Serial ATA RAID Host Adapters � real hardware RAID. Work with 2.4.x
> kernel's megaraid2 driver (same one as for SCSI). Cards use an Intel
> GC80302 dedicated I/O processor. This chipset, under its former AMI
> brand name, has had a long and excellent history with SCSI gear.
> Optional battery backup unit is available for the model 150-6 card's
> cache, for more reliable operation in the event of power loss, etc.
> These cards should not be confused with the low-end LSI Logic MegaRaid
> SATA 150-2 card."
> 
> Skimming for source now to do the same size comparison....
> 
> -Jack

Re: [9fans] Any one going to change to sata disks?

[Ronald G Minnich]

jmk@plan9.bell-labs.com wrote:

> I think we need to focus here

dammit, jim, where's the fun in that?

oh, all right, we'll focus, but it's much more fun to pretend we're barbie.

ron

Re: Re: Re: [9fans] Any one going to change to sata disks?

[andrey mirtchovski]

I think I got called Barbie, I think that's a first and some progress
after all :)

Re: Re: Re: [9fans] Any one going to change to sata disks?

[jmk]

On Fri Jun 30 14:37:01 EDT 2006, mirtchovski@gmail.com wrote:
> I think I got called Barbie, I think that's a first and some progress
> after all :)

Utilikilts don't come in pink, Andrey.

Re: Re: Re: Re: [9fans] Any one going to change to sata disks?

[David Leimbach]

On 6/30/06, andrey mirtchovski <mirtchovski@gmail.com> wrote:
> I think I got called Barbie, I think that's a first and some progress
> after all :)
>
It certainly is new,  Andrea^H^H^H^H erm...

Re: Re: [9fans] Any one going to change to sata disks?

[Jack Johnson]

On 6/30/06, jmk@plan9.bell-labs.com <jmk@plan9.bell-labs.com> wrote:
> I had to go back and read the thread to see how we got here:
>
>         1) some piece of hardware which no real effort has been made
>        to programme doesn't work right;
>         2) familiar discussion about hardware, drivers, documentation;
>         3) suggestion is to buy a much more expensive piece of
>            hardware with similar lack of documentation.
>
> We haven't invested any effort in making the free hardware we
> get on almost every motherboard work, maybe someone should try.

It looked like Geoff and Andrey were just starting down that path,
seeing if they were using the same chipset, and you missed Ron:

         2b) standards developed by vendor committees suck

which is how I devolved into 3.  In general, though Plan 9 does a
decent job of supporting the free hardware that comes with every
motherboard, it does have a history of finding a handful of good
choices and supporting those well (video and USB audio as good
examples).  The archives are full of similar discussions when every
other motherboard vendor shipped a different onboard SCSI controller,
and ultimately the relatively sane and supportable choices were weeded
from the mix.

Admittedly, none of which was done by me.  It's obvious I'm out of my
league.  But, I don't think the above is an unfair observation of the
process that came before.

Perhaps the question I should have asked should not have been about
specific hardware.  The general question should have been: given that
there are SATA controllers out there that mimic SCSI controllers, is
it probable that it would be easier to support one of these than the
early-generation or current SATA chipsets floating around, or would
that be a short-sighted approach?

> I think we need to focus here.

Sorry,

-Jack

Re: Re: [9fans] Any one going to change to sata disks?

[geoff]

At least the Silicon Image SATA controllers seem to emulate the usual
ATA/IDE interface and work with our existing ATA cpu-kernel driver;
the fs kernel driver may lack their PCI VIDs and DIDs.  I'll check.

Re: Re: [9fans] Any one going to change to sata disks?

[geoff]

The fs kernel's sdata.c hadn't been recognising Silicon Image's and
other VIDs and DIDs recognised by the current cpu kernel's sdata.c
I've just updated source's /sys/src/fs/pc/sdata.c to incorporate the
atapnp() code from the cpu kernel to recognise Silicon Image SATA,
Nvidia, ATI, Serverworks and other controllers.

Re: [9fans] Any one going to change to sata disks?

[geoff]

To summarise, sdmv50xx.c in the cpu/terminal kernels will drive the
Marvell 50[48]1 controllers, but should work with any of the
[56]0[48][01] controllers, I believe, with just minor tweaks to
mv50pnp().  I have a working sdmv50xx.c for the file server kernel, at
least it works with the 4 Hitachi SATA disks Coraid provided for
testing, and with the Marvell 88SX5041 (4 SATA-I ports with flash)
controller.  I've added a "statm" file server command, analogous to
statd and stati, so it's possible to get some measurements.  It seems
quite fast, but perhaps I'm easily impressed.  Coraid have made some
changes to their original devsata0.c driver since Russ turned it into
sdmv50xx.c for the cpu kernels, and these help cope with odd disks and
may give some performance improvement.  I'm still trying to merge
these changes into the file server kernel's sdmv50xx.c.

As an aside, sdata.c in the file server kernel may be a little faster
now because I removed some excessively cautious locking from it that I
originally added out of paranoia.