Port Multiplier access with Sil 3124

Port Multiplier access with Sil 3124

[Linda Walsh]

Is there something different, from normal disk-access, that I need to do
to access hard disks beyond '1', on a port-multiplier?

I thought I remembered reading the port multiplier support was
working for many SATA and SATA RAID controller capable chipsets,
including the Sil 3124.

I picked up a 2-Bay external SATA enclosure that I'm trying to access in
(what I thought) was the simplest mode: "JBOD".  However, when I boot,
I am only seeing the first hard disk.

Experimenting, I tried a single hard disk in both positions -- one
position let me see the disk directly (as though it was a direct,
str8-thru connection), the other position showed up detected by
the boot BIOS as a 7MB HD by some unrecognized vendor.   In
linux, I'm able to access and use the hard disk when it appears
'str8-thru', but linux sees nothing concerning the 7MB pseudo HD.

Is my expectation that the driver would simply recognize the
external enclosure by whatever I had the external enclosure set to,
too optimistic?  Do I need to run some special util to setup the disks in
JBOD mode?  I guess I thought I only needed to worry about
'special utils' if I was using the disk-pair in a RAID config (0/1)...

It seems there should be a linux util to manage the "container",
'sil57xx'  --  I take it is not used for RAID-only config?

My ultimate aim is to use it in a RAID-0, mirror config (my luck
with SATA disk drives has been abysmal, of late (*sigh*)).

Anyone with any real-world experience about when the 3Gb SAS
starts to become a bottleneck?  I know that theoretically, it could
support a hair over 350MB/s if there was no overhead, which would
reliably only support 2 hard disks at full speed (assuming ~120MB/s
max linear read speed/disk).  Does that jive with people's real-world 
experience?  I.e. port-multipliers can provide full throughput for
2-HD's but not likely 3? 

Should I be looking for an sil57xx program somewhere (the box contained
a mini-CD, but it looks like a driver for an older kernel (2.6.9).  Not 
so sure about it's usefulness in my setup.

Thanks,
-linda

Re: Port Multiplier access with Sil 3124

[Grant Grundler]

Linda,
Please tell us which kernel version you have and include the dmesg
output. Port multiplier support is generally working in 2.6.26 (and later
releases) for several drivers.  PM support was added after 2.6.20.

Where did you find 350MB/s theoretical?
Link is 8b10b encoded. So it's 10:1 of bits to bytes conversion of link rate.
3Gb/s --> 300MB/s in theory.

For MB/s, it depends on the SATA controller. Don't expect more then
225-235 MB/s per port. At least one sata_sil3124 chip (3126?) is buggy
and won't do more than 120MB/s read for all ports (170 MB/s write).
See linux-ide archives for discussion on this.

On Feb 8, 2009 1:08 PM, "Linda Walsh" <lkml@tlinx.org> wrote:

Is there something different, from normal disk-access, that I need to do
to access hard disks beyond '1', on a port-multiplier?

I thought I remembered reading the port multiplier support was
working for many SATA and SATA RAID controller capable chipsets,
including the Sil 3124.

I picked up a 2-Bay external SATA enclosure that I'm trying to access in
(what I thought) was the simplest mode: "JBOD".  However, when I boot,
I am only seeing the first hard disk.

Experimenting, I tried a single hard disk in both positions -- one
position let me see the disk directly (as though it was a direct,
str8-thru connection), the other position showed up detected by
the boot BIOS as a 7MB HD by some unrecognized vendor.   In
linux, I'm able to access and use the hard disk when it appears
'str8-thru', but linux sees nothing concerning the 7MB pseudo HD.

Is my expectation that the driver would simply recognize the
external enclosure by whatever I had the external enclosure set to,
too optimistic?  Do I need to run some special util to setup the disks in
JBOD mode?  I guess I thought I only needed to worry about
'special utils' if I was using the disk-pair in a RAID config (0/1)...

It seems there should be a linux util to manage the "container",
'sil57xx'  --  I take it is not used for RAID-only config?

My ultimate aim is to use it in a RAID-0, mirror config (my luck
with SATA disk drives has been abysmal, of late (*sigh*)).

Anyone with any real-world experience about when the 3Gb SAS
starts to become a bottleneck?  I know that theoretically, it could
support a hair over 350MB/s if there was no overhead, which would
reliably only support 2 hard disks at full speed (assuming ~120MB/s
max linear read speed/disk).  Does that jive with people's real-world
experience?  I.e. port-multipliers can provide full throughput for
2-HD's but not likely 3?
Should I be looking for an sil57xx program somewhere (the box contained
a mini-CD, but it looks like a driver for an older kernel (2.6.9).
Not so sure about it's usefulness in my setup.

Thanks,
-linda

--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Port Multiplier access with Sil 3124

[Greg Freemyer]

On Sun, Feb 8, 2009 at 3:38 PM, Linda Walsh <lkml@tlinx.org> wrote:
> Is there something different, from normal disk-access, that I need to do
> to access hard disks beyond '1', on a port-multiplier?
>
> I thought I remembered reading the port multiplier support was
> working for many SATA and SATA RAID controller capable chipsets,
> including the Sil 3124.
>
> I picked up a 2-Bay external SATA enclosure that I'm trying to access in
> (what I thought) was the simplest mode: "JBOD".  However, when I boot,
> I am only seeing the first hard disk.
>
> Experimenting, I tried a single hard disk in both positions -- one
> position let me see the disk directly (as though it was a direct,
> str8-thru connection), the other position showed up detected by
> the boot BIOS as a 7MB HD by some unrecognized vendor.   In
> linux, I'm able to access and use the hard disk when it appears
> 'str8-thru', but linux sees nothing concerning the 7MB pseudo HD.
>
> Is my expectation that the driver would simply recognize the
> external enclosure by whatever I had the external enclosure set to,
> too optimistic?  Do I need to run some special util to setup the disks in
> JBOD mode?  I guess I thought I only needed to worry about
> 'special utils' if I was using the disk-pair in a RAID config (0/1)...
>
> It seems there should be a linux util to manage the "container",
> 'sil57xx'  --  I take it is not used for RAID-only config?
>
> My ultimate aim is to use it in a RAID-0, mirror config (my luck
> with SATA disk drives has been abysmal, of late (*sigh*)).

I assume you mean raid-1.  I'm seeing a lot of people lose data even
with that.  There seem to be a lot of firmware specific bugs recently
(not just seagate). Be sure and mix vendors / batches / etc. in an
effort to keep away from near simultaneous double disk failure.

> Anyone with any real-world experience about when the 3Gb SAS
> starts to become a bottleneck?  I know that theoretically, it could
> support a hair over 350MB/s if there was no overhead, which would
> reliably only support 2 hard disks at full speed (assuming ~120MB/s
> max linear read speed/disk).

In my real world tests I've never seen a single drive achieve beyond
about 80MB/sec.  (5GB/min is the way I actually measure it.  That was
using SATA directly on the MB which I assume is as fast a PCIe.)

But very few people have a heavy linear read / write load (I do, but
my use case is unusual).

Most apps use random i/o.  That is where raid in general should shine.
 That includes a PMP setup I assume.

> Does that jive with people's real-world
> experience?  I.e. port-multipliers can provide full throughput for
> 2-HD's but not likely 3?
> Should I be looking for an sil57xx program somewhere (the box contained
> a mini-CD, but it looks like a driver for an older kernel (2.6.9).  Not so
> sure about it's usefulness in my setup.
>
> Thanks,
> -linda
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Greg Freemyer
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
First 99 Days Litigation White Paper -
http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com

Re: Port Multiplier access with Sil 3124

[Mark Lord]

Greg Freemyer wrote:
> In my real world tests I've never seen a single drive achieve beyond
> about 80MB/sec.  (5GB/min is the way I actually measure it.  That was
> using SATA directly on the MB which I assume is as fast a PCIe.)
..

I have had spinning drives here that coulw achieve a simple linear
read rate of 112Mbytes/sec.

Any amount of seeking thrown in and that number drops a lot,
but that's the current max I know of.

There are SATA SSDs in the wild already that are *way* faster, though.

Cheers

Re: Port Multiplier access with Sil 3124

[Linda Walsh]

Grant Grundler wrote:
> Linda,
> Please tell us which kernel version you have and include the dmesg
> output. Port multiplier support is generally working in 2.6.26 (and later
> releases) for several drivers.  PM support was added after 2.6.20.
---
    Sorry.  I'm a bit behind the edge at 2.6.27.3 --
but I tried a boot w/2.6.28.3 and didn't see a difference (had to return
to 27.3 as I accidently disabled a different driver and haven't regened it.

>
> Where did you find 350MB/s theoretical?
> Link is 8b10b encoded. So it's 10:1 of bits to bytes conversion of link rate.
> 3Gb/s --> 300MB/s in theory.
---
    Yep.  Forgot about that... was forgetting about the 2-bits of overhead,
so was using 3Gb/8/(1024*1024) -> 357.6, which I rounded down to 350... 
but forgot about the 10/8 encoding (just as I get rid of that conversion
habit from modem days, now I have to remember it as a special case for
SATA...:-)  ).

>
> For MB/s, it depends on the SATA controller. Don't expect more then
> 225-235 MB/s per port. At least one sata_sil3124 chip (3126?) is buggy
> and won't do more than 120MB/s read for all ports (170 MB/s write).
> See linux-ide archives for discussion on this.
---
    That's horrible!  I'd definitely call that a bug.  Right now,
the fastest I'm getting on my single ATA's is 70-80MB/s.  I could
get that per/ATA port.  So 120MB read for 4 SATA ports would be
a giant step backwards (170MB/s write?  write faster than read?)

Re: Port Multiplier access with Sil 3124

[Linda Walsh]

Greg Freemyer wrote:
> On Sun, Feb 8, 2009 at 3:38 PM, Linda Walsh <lkml@tlinx.org> wrote:
>>
>> My ultimate aim is to use it in a RAID-0, mirror config (my luck
>> with SATA disk drives has been abysmal, of late (*sigh*)).
>
> I assume you mean raid-1. 
Whichever is the mirror mode.  I always have to look it up.

>  I'm seeing a lot of people lose data even
> with that.  There seem to be a lot of firmware specific bugs recently
> (not just seagate). Be sure and mix vendors / batches / etc. in an
> effort to keep away from near simultaneous double disk failure.
----
    Now wait a second -- DIFFERENT vendors?  That goes against the
normal "best practices" with RAID -- to use the same Make/Model for
RAID.  I've never heard of anyone suggesting using different vendors
for RAID disks.  Theoretically (and often in practice), each vendor varies
in speed -- even internal layout.  You can have 2 disks of same size
from different vendors, but there's no guarantee that they are laid
out the same internally.  If they aren't matched your RAID performance
will be significantly slower than a single hard disk.
>
>> Anyone with any real-world experience about when the 3Gb SAS
>> starts to become a bottleneck?  I know that theoretically, it could
>> support a hair over 350MB/s if there was no overhead, which would
>> reliably only support 2 hard disks at full speed (assuming ~120MB/s
>> max linear read speed/disk).
>
> In my real world tests I've never seen a single drive achieve beyond
> about 80MB/sec.  (5GB/min is the way I actually measure it.  That was
> using SATA directly on the MB which I assume is as fast a PCIe.)
---
    Sorry...I must have been misremembering or thinking of SAS drives. 
For my current drives I'm topping out at 80, some in the 70's.  Weird.
I thought I remembered some benchmarking I did that ran faster than
that.  I must be remembering something else. 

    For "top speed, linear read" tests, I use "hdparm -t --direct
/dev/[sh]d[a-z]".  Next fastest is using "dd" with the iflag/oflag
direct and large block sizes. 

> But very few people have a heavy linear read / write load (I do, but
> my use case is unusual).
>
> Most apps use random i/o.  That is where raid in general should shine.
>  That includes a PMP setup I assume.
----
    PMP?  The only reduction in RAID seek time I can think of would be
having the linear seek time reduced by 2 or 3 (for data spread out over
2 or 3 disks).  Is that what you mean?  I wouldn't see much improvement
in rotational or head-settle delay components of seek times.

    It is likely most of my apps are random-seek and get considerably
less throughput -- and going over a network slows things down as well
I drop to about 20-21MB/s for large  writes to a single HD.

    However, my most time consuming operations involve *backups*.  My
worst partitions are not really worth gzipping -- about 6-7% size benefit
on my biggest partition (mostly media files).

Re: Port Multiplier access with Sil 3124

[Greg Freemyer]

On Mon, Feb 9, 2009 at 5:22 PM, Linda Walsh <suse@tlinx.org> wrote:
> Greg Freemyer wrote:
>>
>> On Sun, Feb 8, 2009 at 3:38 PM, Linda Walsh <lkml@tlinx.org> wrote:
>>>
>>> My ultimate aim is to use it in a RAID-0, mirror config (my luck
>>> with SATA disk drives has been abysmal, of late (*sigh*)).
>>
>> I assume you mean raid-1.
>
> Whichever is the mirror mode.  I always have to look it up.
>
>>  I'm seeing a lot of people lose data even
>> with that.  There seem to be a lot of firmware specific bugs recently
>> (not just seagate). Be sure and mix vendors / batches / etc. in an
>> effort to keep away from near simultaneous double disk failure.
>
> ----
>   Now wait a second -- DIFFERENT vendors?  That goes against the
> normal "best practices" with RAID -- to use the same Make/Model for
> RAID.  I've never heard of anyone suggesting using different vendors
> for RAID disks.

A year ago, neither had I.  SATA drive reliability is in the crapper
in the last 18 months.  I've personally had a double drive failure
that caused data loss.  And I'm hearing lots of similar war stories.

I'm hearing of people saying a 2 disk mirror (raid-1) is not safe
enough.  Go with either a 3 disk mirror or to raid-6.  Even with
raid-6 I personally would not let it have too many spindles. (Whatever
too many means?)

>  Theoretically (and often in practice), each vendor varies
> in speed -- even internal layout.

You will likely be limited by the speed of your slowest disk, so get
ones with similar specs.

> You can have 2 disks of same size
> from different vendors, but there's no guarantee that they are laid
> out the same internally.  If they aren't matched your RAID performance
> will be significantly slower than a single hard disk.

I don't understand that.  Back in the pre-LBA days of 10+ years ago
geometry was a huge issue.  Today, I can't see why it would matter.
Someone please correct me if I'm wrong.

I don't really keep up with drive geometry any more.  Are some
manufactures putting the low sector numbers on the inside and some on
the outside of the platter?  If so, I could see that being an issue.


>>
>>> Anyone with any real-world experience about when the 3Gb SAS
>>> starts to become a bottleneck?  I know that theoretically, it could
>>> support a hair over 350MB/s if there was no overhead, which would
>>> reliably only support 2 hard disks at full speed (assuming ~120MB/s
>>> max linear read speed/disk).
>>
>> In my real world tests I've never seen a single drive achieve beyond
>> about 80MB/sec.  (5GB/min is the way I actually measure it.  That was
>> using SATA directly on the MB which I assume is as fast a PCIe.)
>
> ---
>   Sorry...I must have been misremembering or thinking of SAS drives. For my
> current drives I'm topping out at 80, some in the 70's.  Weird.
> I thought I remembered some benchmarking I did that ran faster than
> that.  I must be remembering something else.
>   For "top speed, linear read" tests, I use "hdparm -t --direct
> /dev/[sh]d[a-z]".  Next fastest is using "dd" with the iflag/oflag
> direct and large block sizes.

I do most of my tests with dd, but then my actual use case is normally
using dd as well, so it only makes sense for me to test that way.

>>
>> But very few people have a heavy linear read / write load (I do, but
>> my use case is unusual).
>>
>> Most apps use random i/o.  That is where raid in general should shine.
>>  That includes a PMP setup I assume.
>
> ----
>   PMP?

PMP == Port Multiplier

> The only reduction in RAID seek time I can think of would be
> having the linear seek time reduced by 2 or 3 (for data spread out over
> 2 or 3 disks).  Is that what you mean?  I wouldn't see much improvement
> in rotational or head-settle delay components of seek times.

It's been 10 years since I took my raid training classes from Compaq
(previously DEC, now HP).  We covered performance as part of that.  At
that time we did not even discuss linear read speed.  It was all io's
/ second.

So assume with one disk you can do 2,000 ios/second and each io is
16K.  (A database might do something like this.)   That is only 32
MB/sec.

Now assume you do a 8-disk raid-0 (pure stripping, very dangerous).

You should be able to get 8x the ios.  So 16,000 ios/second and 248 MB / sec.

I haven't done the benchmarks but the above seems pretty reasonable to
actually achieve.

OTOH, if you are just looking at linear disk speed, then a 8-disk
array is likely not going to perform anywhere near as fast as 8x a
single drive.  ie. The drives are no longer the bottleneck.

>   It is likely most of my apps are random-seek and get considerably
> less throughput -- and going over a network slows things down as well
> I drop to about 20-21MB/s for large  writes to a single HD.
>
>   However, my most time consuming operations involve *backups*.  My
> worst partitions are not really worth gzipping -- about 6-7% size benefit
> on my biggest partition (mostly media files).

If you combine LVM (or Device Mapper) snapshots with raid you have a
pretty ideal situation.

Add enough drives (spindles) to your setup so that you can easily
handle both your primary load and your backup load and the load
associated with having a snapshot in place.  I would bet 5 or 6 drives
total would do the trick.

Then use snapshots to give you a "instant in time" snapshot to backup from.

If you can get the backup done in under 24 hours, then you can make a
backup every day with little or no interference with your primary
load.

HTH
Greg
-- 
Greg Freemyer
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
First 99 Days Litigation White Paper -
http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com

Re: Port Multiplier access with Sil 3124

[Jeff Garzik]

Greg Freemyer wrote:

> I'm hearing of people saying a 2 disk mirror (raid-1) is not safe
> enough.  Go with either a 3 disk mirror or to raid-6.  Even with
> raid-6 I personally would not let it have too many spindles. (Whatever
> too many means?)

IMO, RAID-1 was never safe.  With RAID-1, one must rely solely on 
"knowing" which RAID component is bad.  With a completely dead drive, 
this is obvious; with slowly creeping bad sectors, far less obvious.

Plus, the biggest crime, in my opinion, is the lack of checksumming or 
any other method of actually verifying your data.

I've been waiting for years for someone to write RAID-1f...  RAID-1 with 
a hash function that writes checksums in a special metadata area (just 
like the other pre-existing RAID metadata...  a RAID partition is really 
a just simple filesystem anyway).

That way you _know_ with 100% certainty that your data is OK (or not), 
even if you only have a single drive.

	Jeff

Re: Port Multiplier access with Sil 3124

[Linda Walsh]

Jeff Garzik wrote:
> Greg Freemyer wrote:
> 
>> I'm hearing of people saying a 2 disk mirror (raid-1) is not safe
>> enough.  Go with either a 3 disk mirror or to raid-6.  Even with
>> raid-6 I personally would not let it have too many spindles. (Whatever
>> too many means?)
> 
> IMO, RAID-1 was never safe.  With RAID-1, one must rely solely on 
> "knowing" which RAID component is bad.  With a completely dead drive, 
> this is obvious; with slowly creeping bad sectors, far less obvious.
---
	I had a similar thought -- how would I know if the
2-disks are actually "in sync"?

	I'm  guessing I could physically remove each and try to access
them as single-drives and they should be the same, but I don't know that
the RAID-1 format will store the data on each drive to exactly look
like a single mounted disk.  I can't think of how else they might
do it, or why, but I just haven't physically verified that I an
pull either HD and access it as a solo-hard disk.  (I'd hope so...but
until I've actually tried it with the hardware in question...)

	But all of this is really depressing me.  Just throw up my hands
and give up on computer storage?

	That hardly seems right.

	FYI -- my drive failures, recently, have kill my *backup*
hard disks.  All of my failures have been on my "newer", larger
hard disks that I use for backup purposes.

	I also had a triple Seagate drive failure within 2 months,
two of them within a week -- and I did lose *backups* of my primary
drives!

	That's just bas-ackwards.  My "plan" was to go to RAID-1
for my ****backup**** hard disks.  Most of my primary hard disks are
SCSI or SAS and they've been unaffected by the SATA pathos.

Re: Port Multiplier access with Sil 3124

[Greg Freemyer]

On Mon, Feb 9, 2009 at 7:15 PM, Jeff Garzik <jeff@garzik.org> wrote:
> Greg Freemyer wrote:
>
>> I'm hearing of people saying a 2 disk mirror (raid-1) is not safe
>> enough.  Go with either a 3 disk mirror or to raid-6.  Even with
>> raid-6 I personally would not let it have too many spindles. (Whatever
>> too many means?)
>
> IMO, RAID-1 was never safe.  With RAID-1, one must rely solely on "knowing"
> which RAID component is bad.  With a completely dead drive, this is obvious;
> with slowly creeping bad sectors, far less obvious.
>
> Plus, the biggest crime, in my opinion, is the lack of checksumming or any
> other method of actually verifying your data.
>
> I've been waiting for years for someone to write RAID-1f...  RAID-1 with a
> hash function that writes checksums in a special metadata area (just like
> the other pre-existing RAID metadata...  a RAID partition is really a just
> simple filesystem anyway).
>
> That way you _know_ with 100% certainty that your data is OK (or not), even
> if you only have a single drive.
>
>        Jeff

Jeff,

I guess you know the scsi standard is in the process of getting
expanded such that each sector can optionally have a well known hash.
And that the hash can be provided by the kernel as part of the data
write.  In turn it can be read as part of the sector on a data read.

Thus it will be possible to have true end-to-end reliability in a
single disk environment.  Who knows when hardware will start to show
up.  If anyone on this list has any influence on the T13 (ata) spec
people, I think it would be a great addition to the ATA world as well
as for the scsi world.

You can google for "SCSI DIF/DIX extensions"

The linux block layer, dm, and mdraid are all gaining support.  Maybe
you can figure out an efficient way to leverage that infrastructure
and implement raid-1f via libata and normal drives!!!

Greg



-- 
Greg Freemyer
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
First 99 Days Litigation White Paper -
http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com

Re: Port Multiplier access with Sil 3124

[Jeff Garzik]

Linda Walsh wrote:
> Jeff Garzik wrote:
>> Greg Freemyer wrote:
>>
>>> I'm hearing of people saying a 2 disk mirror (raid-1) is not safe
>>> enough.  Go with either a 3 disk mirror or to raid-6.  Even with
>>> raid-6 I personally would not let it have too many spindles. (Whatever
>>> too many means?)
>>
>> IMO, RAID-1 was never safe.  With RAID-1, one must rely solely on 
>> "knowing" which RAID component is bad.  With a completely dead drive, 
>> this is obvious; with slowly creeping bad sectors, far less obvious.
> ---
>     I had a similar thought -- how would I know if the
> 2-disks are actually "in sync"?
> 
>     I'm  guessing I could physically remove each and try to access
> them as single-drives and they should be the same, but I don't know that
> the RAID-1 format will store the data on each drive to exactly look
> like a single mounted disk.  I can't think of how else they might
> do it, or why, but I just haven't physically verified that I an
> pull either HD and access it as a solo-hard disk.  (I'd hope so...but
> until I've actually tried it with the hardware in question...)
> 
>     But all of this is really depressing me.  Just throw up my hands
> and give up on computer storage?

Find a solution that has both replication and checksumming :)

Trust no component!  :)

	Jeff

Re: Port Multiplier access with Sil 3124

[Tejun Heo]

Linda Walsh wrote:
>     I also had a triple Seagate drive failure within 2 months,
> two of them within a week -- and I did lose *backups* of my primary
> drives!

My test disks go through a lot of unusual workloads which often
include frequent emergency head unloads with immediately following
spin up and Seagate has been the sturdiest for quite some time now.
It's sad to hear that they're degressing.  :-(

-- 
tejun

Re: Port Multiplier access with Sil 3124

[Tejun Heo]

Linda Walsh wrote:
> It seems there should be a linux util to manage the "container",
> 'sil57xx'  --  I take it is not used for RAID-only config?

sil57xx should generally work fine as PMP device.  There has been some
detection related problem with recent firmwares which isn't fixed yet
but it should generally work.  The hardest part is to put the chip
into vanilla PMP mode.  The reference board I have has this rotary
switch and I need to put it into JBOD mode and press another small
mode-set switch to actually make the transition.

Can you post kernel boot log?

--
tejun

Re: Port Multiplier access with Sil 3124

[Robert Hancock]

Tejun Heo wrote:
> Linda Walsh wrote:
>>     I also had a triple Seagate drive failure within 2 months,
>> two of them within a week -- and I did lose *backups* of my primary
>> drives!
> 
> My test disks go through a lot of unusual workloads which often
> include frequent emergency head unloads with immediately following
> spin up and Seagate has been the sturdiest for quite some time now.
> It's sad to hear that they're degressing.  :-(

It seems like most of the problems have been firmware and not 
mechanical, but a coworker did have a Seagate 7200.11 disk recently 
start getting SMART errors, which doesn't seem like any of the usual 
firmware symptoms that have been reported.

Went with a WD Caviar Black for a recent drive purchase instead.. 
hopefully Seagate will get their act together for the next models.