LSI doesn't recommend this and warns against possible
data inconsistencies/losses. No further reason given
(or at least I didn't find it in their web pages).

Nevertheless, did anybody out there try this? Results?

-- 
Michael Giegerich

"Michael Giegerich" <migieger@web.de> wrote in message news:huit0f.kc32.ln@luva.dyndns.org
> LSI doesn't recommend this and warns against possible
> data inconsistencies/losses. No further reason given
> (or at least I didn't find it in their web pages).

Sounds like they made a lemon and still try to sell it without fixing it.
If it wasn't designed to be able to do this then it simply wouldn't let 
you do it.

> 
> Nevertheless, did anybody out there try this? Results?

>"Michael Giegerich" <migieger@web.de> wrote in message 
>news:huit0f.kc32.ln@luva.dyndns.org...
>
> LSI doesn't recommend this and warns against possible
> data inconsistencies/losses. No further reason given
> (or at least I didn't find it in their web pages).

How was it worded? Were they just warning people not to do something 
obviously dumb like combining SAS and SATA drives into the same array?

If they are saying not to have a SAS array and a separate SATA array on the 
same controller then I agree with Frank

John L Rice 

John L Rice:
> >"Michael Giegerich" <migieger@web.de> wrote in message 
> >news:huit0f.kc32.ln@luva.dyndns.org...
> >
> > LSI doesn't recommend this and warns against possible
> > data inconsistencies/losses. No further reason given
> > (or at least I didn't find it in their web pages).
> 
> How was it worded? Were they just warning people not to do something 
> obviously dumb like combining SAS and SATA drives into the same array?
> 
> If they are saying not to have a SAS array and a separate SATA array on the 
> same controller then I agree with Frank

This one.

-- 
Michael Giegerich

In article <0ksi1f.2e31.ln@luva.dyndns.org>, migieger@web.de says...
>
>John L Rice:
>> >"Michael Giegerich" <migieger@web.de> wrote in message 
>> >news:huit0f.kc32.ln@luva.dyndns.org...
>> >
>> > LSI doesn't recommend this and warns against possible
>> > data inconsistencies/losses. No further reason given
>> > (or at least I didn't find it in their web pages).
>> 
>> How was it worded? Were they just warning people not to do something 
>> obviously dumb like combining SAS and SATA drives into the same array?
>> 
>> If they are saying not to have a SAS array and a separate SATA array on the 
>> same controller then I agree with Frank
>
it's actually due to the difference in rotational vibration that you're
not supposed to put both SAS & SATA drivers into the same array 
  _____                         .     .
 '    \\                  .                .                       |>>
     O//             .                        .                    |
    \_\          .                              .                  |
    | |      .                                    .      .         |
   /  |  .          www.EvenEnterprises.com        .   .    .      |
  /  .|            info@EvenEnterprises.com         . .      .     |
 / .  |         310-544-9439 / 310-544-9309 fax      .        .  . o
----------------------------------------------------------------------
Authorized - DIRECT VAR/VAD/Distributor for new mid-high end storage
iSCSI/NAS/SAN/RAID from EMC, HP, Equallogic, Quantum, OverLand Storage

Andy:
> In article <0ksi1f.2e31.ln@luva.dyndns.org>, migieger@web.de says...
> >
> >John L Rice:
> >> >"Michael Giegerich" <migieger@web.de> wrote in message 
> >> >news:huit0f.kc32.ln@luva.dyndns.org...
> >> >
> >> > LSI doesn't recommend this and warns against possible
> >> > data inconsistencies/losses. No further reason given
> >> > (or at least I didn't find it in their web pages).
> >> 
> >> How was it worded? Were they just warning people not to do something 
> >> obviously dumb like combining SAS and SATA drives into the same array?
> >> 
> >> If they are saying not to have a SAS array and a separate SATA array on the 
> >> same controller then I agree with Frank
> >
> it's actually due to the difference in rotational vibration that you're
> not supposed to put both SAS & SATA drivers into the same array 

Because a SCSI drive rotating at 15,000 rpm
would harm a SATA drive at 7,200 rpm?

Then it should be advised against to mix SATA
and SCSI drives on the same controller or even
in the same computer housing... :-)

Honestly, why would this be a reason?

-- 
Michael Giegerich

Michael Giegerich wrote:

> Because a SCSI drive rotating at 15,000 rpm
> would harm a SATA drive at 7,200 rpm?
> 
> Then it should be advised against to mix SATA
> and SCSI drives on the same controller or even
> in the same computer housing... :-)
> 
> Honestly, why would this be a reason?
> 

I don't know if this is the reason, but mechanical systems tend to 
resonate.  If, for example, you put a bunch of similar pendulum clocks 
in a room, after a while all will have the same period.

Generators will sync together, motors will run at the same speed.

I can see that having a 7200 RPM and 15000 RPM motor in close proximity, 
especially in a computer case which vibrates, could cause problems...

So I agree with you, it's weird but I can see the sense.

Maybe it's lawyer-ese for "If the drives fail and they're not on the 
same controller, you can't blame us.  If they're on the same controller, 
you can blame us."  :-|

"John L Rice" <Drummer@ImJohn.com> wrote in message news:133pqc48polauc1@corp.supernews.com
> > "Michael Giegerich" <migieger@web.de> wrote in message news:huit0f.kc32.ln@luva.dyndns.org...
> > 
> > LSI doesn't recommend this and warns against possible
> > data inconsistencies/losses. No further reason given
> > (or at least I didn't find it in their web pages).
> 
> How was it worded? Were they just warning people not to do something

> obviously dumb 

Nonsense.

> like combining SAS and SATA drives into the same array?

 There is nothing obviously dumb about it.

> 
> If they are saying not to have a SAS array and a separate SATA array on the
> same controller then I agree with 

> Frank.

Who? 

> 
> John L Rice

 Do your brainfarts happen often?

"Andy" <info@evenenterprises.com> wrote in message news:i710i.74420$Fk2.38096@newsfe08.phx
> In article <0ksi1f.2e31.ln@luva.dyndns.org>, migieger@web.de says...
> > John L Rice:
> > > > "Michael Giegerich" migieger@web.de> wrote in message news:huit0f.kc32.ln@luva.dyndns.org...
> > > > 
> > > > LSI doesn't recommend this and warns against possible
> > > > data inconsistencies/losses. No further reason given
> > > > (or at least I didn't find it in their web pages).
> > > 
> > > How was it worded? Were they just warning people not to do something
> > > obviously dumb like combining SAS and SATA drives into the same array?
> > > 
> > > If they are saying not to have a SAS array and a separate SATA array on the
> > > same controller then I agree with Frank
>
> it's actually due to the difference in rotational vibration that you're
> not supposed to put both SAS & SATA drivers into the same array

But adding them as single drives outside an array would be fine.
Yup, that obviously makes sense.

>   _____                         .     .
>  '    \\                  .                .                       |>>
>      O//             .                        .                    |
>     \_\          .                              .                  |
>     | |      .                                    .      .         |
>    /  |  .          www.EvenEnterprises.com        .   .    .      |
>   /  .|            info@EvenEnterprises.com         . .      .     |
>  / .  |         310-544-9439 / 310-544-9309 fax      .        .  . o
> ----------------------------------------------------------------------
> Authorized - DIRECT VAR/VAD/Distributor for new mid-high end storage
> iSCSI/NAS/SAN/RAID from EMC, HP, Equallogic, Quantum, OverLand Storage

Here's another store to avoid. Thanks for the warning.

Michael Giegerich <migieger@web.de> kenjka:
> LSI doesn't recommend this and warns against possible
> data inconsistencies/losses. No further reason given
> (or at least I didn't find it in their web pages).

SATA and SCSI/SAS drives spin in different direction, that's the reason
why it's not recommended installing both type of drives in the same case...

Quotation:
Although SAS and SATA are compatible, Mike Karp of Enterprise Management
Associates cautions against mixing different drives in the same enclosure. 

"Only put drives of the same speed in the same bay," he advises. "Devices
spinning at different speeds cause vibration, and there is a danger that
drives can unset or cause errors in reads and writes."

http://www.serverwatch.com/hreviews/article.php/3619016


-- 
"Bijesans li celavacu izdrkavu ?" upita Misko bulji Ficou pozdravlju. 
 "Nisam ja nikog bombardiro !" rece majoneza trci "Ja samo rostiljog ljubija blesavm !"  By runf

                                  Damir Lukic, calypso@_MAKNIOVO_fly.srk.fer.hr
                                  a member of hr.comp.hardver FAQ-team

<calypso@fly.srk.fer.hr.invalid> wrote in message news:f1v5ar$svf$1@news1.carnet.hr
> Michael Giegerich <migieger@web.de> kenjka:
> > LSI doesn't recommend this and warns against possible
> > data inconsistencies/losses. No further reason given
> > (or at least I didn't find it in their web pages).

> SATA and SCSI/SAS drives spin in different direction, 

Bwahahah (ROTFLOL).

> that's the reason  why it's not recommended installing both type of 
> drives in the same case...

Actually, it would be a perfect reason for doing that IF it were true
AND the vibration pattern would be rotation direction (phase) dependent.
They could actually cancel themselves out. 
The reason that doesn't work is the same reason that it doesn't matter.
Even drives of same RPM can be in and out of sync, vibration wise.

> 
> Quotation:
> Although SAS and SATA are compatible, Mike Karp of 

> Enterprise Management Associates 

A people for hire busyness.

> cautions against mixing different drives in the same enclosure.

> "Only put drives of the same speed in the same bay," he advises. 
> "Devices spinning at different speeds cause vibration, and there is 
> a danger that drives can unset or cause errors in reads and writes."

Single drives cause vibration, drives of same model cause vibration,
drives of same speed cause vibration and drives of different speed 
cause vibration too. So what. It's not that they go shake the cabinet.    
If they manage to work themselves loose they are in badly designed trays.

> 
> http://www.serverwatch.com/hreviews/article.php/3619016

Nothing there about drive spin directions.

>> If they are saying not to have a SAS array and a separate SATA array on 
>> the
>> same controller then I agree with
>
>> Frank.
>
> Who?

uuhhmm . . . you . . .  (seriously, I don't know what the hell I was 
thinking.  Did you ever use the name 'Frank'??)


>> John L Rice
>
> Do your brainfarts happen often?

Yeah . . .QUITE often . . it's pretty stinky here . . . .  ;~?

Obviously, I'm much more proficient at lurking . . . . 

"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message 
news:46449272$0$97266$892e7fe2@authen.yellow.readfreenews.net...
> <calypso@fly.srk.fer.hr.invalid> wrote in message 
> news:f1v5ar$svf$1@news1.carnet.hr
>> Michael Giegerich <migieger@web.de> kenjka:
>> > LSI doesn't recommend this and warns against possible
>> > data inconsistencies/losses. No further reason given
>> > (or at least I didn't find it in their web pages).
>
>> SATA and SCSI/SAS drives spin in different direction,
>
> Bwahahah (ROTFLOL).
>
>> that's the reason  why it's not recommended installing both type of
>> drives in the same case...
>
> Actually, it would be a perfect reason for doing that IF it were true
> AND the vibration pattern would be rotation direction (phase) dependent.
> They could actually cancel themselves out.
> The reason that doesn't work is the same reason that it doesn't matter.
> Even drives of same RPM can be in and out of sync, vibration wise.
>
>>
>> Quotation:
>> Although SAS and SATA are compatible, Mike Karp of
>
>> Enterprise Management Associates
>
> A people for hire busyness.
>
>> cautions against mixing different drives in the same enclosure.
>
>> "Only put drives of the same speed in the same bay," he advises.
>> "Devices spinning at different speeds cause vibration, and there is
>> a danger that drives can unset or cause errors in reads and writes."
>
> Single drives cause vibration, drives of same model cause vibration,
> drives of same speed cause vibration and drives of different speed
> cause vibration too. So what. It's not that they go shake the cabinet.
> If they manage to work themselves loose they are in badly designed trays.
>
>>
>> http://www.serverwatch.com/hreviews/article.php/3619016
>
> Nothing there about drive spin directions.

Hopefully this warning is mostly BS.  I just recently finished changing my 
DAW (Digital Audio Workstation) PC from using an external CRU Dataport SCSI 
rack (for sale, headed soon to an Ebay listing near you) to an internal 
Supermicro 5 bay SAS/SATA enclosure with two SAS drives and two SATA drives. 
(Adaptec 48300 controller)  So far it's working fine.  I'll post back here 
if they disassemble themselves from the 'vibrations' . . . .

John L Rice 

"John L Rice" <Drummer@ImJohn.com> wrote in message news:134ahc0p6fmfqec@corp.supernews.com...
} >> If they are saying not to have a SAS array and a separate SATA array on 
} >> the same controller then I agree with
} >
} >> Frank.
} >
} > Who?
} 
} uuhhmm . . . you . . .  (seriously, I don't know what the hell I was 
} thinking.  Did you ever use the name 'Frank'??)

You mean: "Frank" <nospam@ (home of the braindead) mindspring.com>
Neh. As far as my records go the last we saw of him was in 2001.
That brainfart of yours must have spent quite some time in the making.
 
} 
} >> John L Rice
} >
} > Do your brainfarts happen often?
} 
} Yeah . . .QUITE often . . it's pretty stinky here . . . .  ;~?
} 
} Obviously, I'm much more proficient at lurking . . . . 
 

<calypso@fly.srk.fer.hr.invalid> wrote in message 
news:f1v5ar$svf$1@news1.carnet.hr...
> Michael Giegerich <migieger@web.de> kenjka:
> SATA and SCSI/SAS drives spin in different direction, that's the reason
> why it's not recommended installing both type of drives in the same 
> case...
>

That is the biggest load of balloney I've ever heard... This is so wrong I'm 
not even going to try a real answer. If you believe that, get out of IT 
fast, you're a danger to anything with a plug on it.

Rob

Rob Turk <wipe_this_r.turk@chello.nl> kenjka:
> That is the biggest load of balloney I've ever heard... This is so wrong I'm 
> not even going to try a real answer. If you believe that, get out of IT 
> fast, you're a danger to anything with a plug on it.

That's not mine... That's  IBM's storage policy AFAIK, they don't mix SATA
and SAS drives in the same case... Why? Ask them, not me, all I know is that
there is a possibility that vibrations of SAS drives can potentially cause
some errors on SATA drives on a long run...


-- 
"Nezdravs li cetniko umire ?" upita macka njusi Samurajo podmazuje. 
 "Nisam ja nikog bombardiro !" rece lubenicao mase "Ja samo drotu pipu pedofilanm !"  By runf

                                  Damir Lukic, calypso@_MAKNIOVO_fly.srk.fer.hr
                                  a member of hr.comp.hardver FAQ-team

<calypso@fly.srk.fer.hr.invalid> wrote in message 
news:f2f5mf$55l$3@news1.carnet.hr...
> Rob Turk <wipe_this_r.turk@chello.nl> kenjka:
>> That is the biggest load of balloney I've ever heard... This is so wrong 
>> I'm
>> not even going to try a real answer. If you believe that, get out of IT
>> fast, you're a danger to anything with a plug on it.
>
> That's not mine... That's  IBM's storage policy AFAIK, they don't mix SATA
> and SAS drives in the same case... Why? Ask them, not me, all I know is 
> that
> there is a possibility that vibrations of SAS drives can potentially cause
> some errors on SATA drives on a long run...
>

Unless you give me a link where IBM makes the clame that the drives spin in 
opposite directions, it's your claim. And it's balloney.

SAS is just an electrical interface and a protocol definition. So is SATA. 
So is SCSI. So is PATA. And so is Fibre Channel, ESDI, ST-506, CMD and SSA. 
They are not in any way related to which direction the disk spins.

Rob

Andy wrote:

>In article <0ksi1f.2e31.ln@luva.dyndns.org>, migieger@web.de says...
>  
>
>>John L Rice:
>>    
>>
>>>>"Michael Giegerich" <migieger@web.de> wrote in message 
>>>>news:huit0f.kc32.ln@luva.dyndns.org...
>>>>
>>>>LSI doesn't recommend this and warns against possible
>>>>data inconsistencies/losses. No further reason given
>>>>(or at least I didn't find it in their web pages).
>>>>        
>>>>
>>>How was it worded? Were they just warning people not to do something 
>>>obviously dumb like combining SAS and SATA drives into the same array?
>>>
>>>If they are saying not to have a SAS array and a separate SATA array on the 
>>>same controller then I agree with Frank
>>>      
>>>
>it's actually due to the difference in rotational vibration that you're
>not supposed to put both SAS & SATA drivers into the same array 
>

Is there any truth to this? I have a JBOD unit that has all SCSI drives 
but some of them are 10K drives and some are 7200's.  They have been 
running for at least four years without a hitch.

I now have a new 1U server that has two 7200 SATA drives mirrored. It 
has two free drive bays and I was planning on putting in two 10K 
Raptors. Is this not advised due to differing rotational speed? I can 
imagine that harmonic vibration would resonate at some other frequencies 
but how does this affect the drives themselves? I'd think it has a lot 
to do with the structure that the drives are in and how well vibrations 
are damped.

What about fans in these 1U servers?  Some of these run at 15K RPM.  I'd 
imagine they would need to be taken into account too and if this was a 
real problem there would be advisories about running certain speed 
drives with certain speed fans. 

Thanks for any information you can give.

Steve

"Rob Turk" <wipe_this_r.turk@chello.nl> wrote in message news:cafbf$464b2688$4df850e0$3021@news.chello.nl
> <calypso@fly.srk.fer.hr.invalid> wrote in message news:f2f5mf$55l$3@news1.carnet.hr...
> > Rob Turk <wipe_this_r.turk@chello.nl> kenjka:
> > > That is the biggest load of balloney I've ever heard... This is so wrong
> > > I'm not even going to try a real answer. If you believe that, get out of IT
> > > fast, you're a danger to anything with a plug on it.
> > 
> > That's not mine... That's  IBM's storage policy AFAIK, they don't mix SATA
> > and SAS drives in the same case... Why? Ask them, not me, all I know is that
> > there is a possibility that vibrations of SAS drives can potentially cause
> > some errors on SATA drives on a long run...
> > 
> 
> Unless you give me a link where IBM makes the clame that the drives spin in
> opposite directions, it's your claim. And it's balloney.

> SAS is just an electrical interface and a protocol definition. So is SATA.

SAS was even given the same connector arrangement as SATA so that 
SAS and SATA drives drives could both be used in SAS cabinets 
(but not in SATA cabinets).

> So is SCSI. So is PATA. And so is Fibre Channel, ESDI, ST-506, CMD and SSA.
> They are not in any way related to which direction the disk spins.
> 
> Rob

What exactly did you not get in the reactions here to that croat clown.

"Steve Cousins" <steve.cousins@maine.edu> wrote in message news:464B3F27.2040900@maine.edu
> Andy wrote:
> > In article <0ksi1f.2e31.ln@luva.dyndns.org>, migieger@web.de says...
> > > John L Rice:
> > > > > "Michael Giegerich" migieger@web.de> wrote in message news:huit0f.kc32.ln@luva.dyndns.org...
> > > > > 
> > > > > LSI doesn't recommend this and warns against possible
> > > > > data inconsistencies/losses. No further reason given
> > > > > (or at least I didn't find it in their web pages).
> > > > > 
> > > > How was it worded? Were they just warning people not to do something
> > > > obviously dumb like combining SAS and SATA drives into the same array?
> > > > 
> > > > If they are saying not to have a SAS array and a separate SATA array on the
> > > > same controller then I agree with Frank
> > > > 
> > it's actually due to the difference in rotational vibration that you're
> > not supposed to put both SAS & SATA drivers into the same array
> > 
> 
> Is there any truth to this? I have a JBOD unit that has all SCSI drives
> but some of them are 10K drives and some are 7200's.  They have been
> running for at least four years without a hitch.
> 
> I now have a new 1U server that has two 7200 SATA drives mirrored. It
> has two free drive bays and I was planning on putting in two 10K
> Raptors. Is this not advised due to differing rotational speed? I can
> imagine that harmonic vibration would resonate at some other frequencies
> but how does this affect the drives themselves? I'd think it has a lot
> to do with the structure that the drives are in and how well vibrations
> are damped.
> 
> What about fans in these 1U servers?  Some of these run at 15K RPM.  I'd
> imagine they would need to be taken into account too and if this was a
> real problem there would be advisories about running certain speed
> drives with certain speed fans.
> 
> Thanks for any information you can give.
> 
> Steve

<calypso@fly.srk.fer.hr.invalid> wrote in message news:f2f5mf$55l$3@news1.carnet.hr
> Rob Turk <wipe_this_r.turk@chello.nl> kenjka:
> > That is the biggest load of balloney I've ever heard... This is so wrong I'm
> > not even going to try a real answer. If you believe that, get out of IT
> > fast, you're a danger to anything with a plug on it.

> That's not mine... That's  IBM's storage policy 

Ah, now it is IBM's fault that you made a spectacular fool out of yourself.

> AFAIK, 

In other words: you made that up.

> they don't mix SATA and SAS drives in the same case... 
> Why? Ask them, not me, 

Too late, you already answered that for them. It's the spin direction.

> all I know 

But you don't.

> is that there is a possibility that vibrations of SAS drives  can 
> potentially cause  some errors on SATA drives on a long run...

Keep up the act, you're quite convincing.

Folkert Rienstra wrote:
> 
> What exactly did you not get in the reactions here to that croat clown.

I sympathised with most of the reactions which is why I was puzzled by
Andy's message that seemed to give creedence to the argument against
mixing types. Since it is similar to what I have done and plan to do in
the future, I thought I'd ask Andy (and others who might have a thought
about it) what the basis was for the message. I haven't found a
resounding credible source for this information so I'll plan on
continuing the practice. I hope I haven't caused disharmony. 

Steve

"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message news:46351fb6$1$97225$892e7fe2@authen.yellow.readfreenews.net...
> "Michael Giegerich" <migieger@web.de> wrote in message news:huit0f.kc32.ln@luva.dyndns.org
>> LSI doesn't recommend this and warns against possible
>> data inconsistencies/losses. No further reason given
>> (or at least I didn't find it in their web pages).
>
> Sounds like they made a lemon and still try to sell it without fixing it.
> If it wasn't designed to be able to do this then it simply wouldn't let
> you do it.
>
>>
>> Nevertheless, did anybody out there try this? Results?

I'm developer of the mpt fusion linux driver.  Mike, who at LSI told you that you can't mix SAS/SATA drives on the 1068?    If your 
running mpt fusion (not megaraid), you can mix SATA and SAS on a single controller as long as the devices are configured at single 
devices, non-raid.  If you create a RAID volume, then it has to all SAS or SATA drives in that raid volume.   Since we support two 
logical volumes, its possible to have one raid volume as SATA, and the other as SAS.  Here is a link to our website containing 
documentation on our products

http://www.lsi.com/storage_home/products_home/host_bus_adapters/sas_hbas/index.html

Eric Moore
LSI Corporation
Eric.Moore@lsi.com

"Eric Moore" <ericmooreco@adelphia.net> wrote in message 
news:hMWdnandxfDPWdbbnZ2dnUVZ_o-knZ2d@adelphia.com...
>
> I'm developer of the mpt fusion linux driver.  Mike, who at LSI told you 
> that you can't mix SAS/SATA drives on the 1068?    If your running mpt 
> fusion (not megaraid), you can mix SATA and SAS on a single controller as 
> long as the devices are configured at single devices, non-raid.  If you 
> create a RAID volume, then it has to all SAS or SATA drives in that raid 
> volume.   Since we support two logical volumes, its possible to have one 
> raid volume as SATA, and the other as SAS.  Here is a link to our website 
> containing documentation on our products
>
> http://www.lsi.com/storage_home/products_home/host_bus_adapters/sas_hbas/index.html
>
> Eric Moore
> LSI Corporation
> Eric.Moore@lsi.com
>

Finally some first-hand information! Thanks for chiming in, Eric.

Rob

"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message 
news:464a4b5e$0$97269$892e7fe2@authen.yellow.readfreenews.net...
> "John L Rice" <Drummer@ImJohn.com> wrote in message 
> news:134ahc0p6fmfqec@corp.supernews.com...
> } >> If they are saying not to have a SAS array and a separate SATA array 
> on
> } >> the same controller then I agree with
> } >
> } >> Frank.
> } >
> } > Who?
> }
> } uuhhmm . . . you . . .  (seriously, I don't know what the hell I was
> } thinking.  Did you ever use the name 'Frank'??)
>
> You mean: "Frank" <nospam@ (home of the braindead) mindspring.com>
> Neh. As far as my records go the last we saw of him was in 2001.
> That brainfart of yours must have spent quite some time in the making.

My subconscious makes a conscientious effort to get my conscious farting 
unconscionably.

John L Rice 

"Rob Turk" <wipe_this_r.turk@chello.nl> wrote in message news:73e55$464bf79f$4df850e0$7993@news.chello.nl
> "Eric Moore" <ericmooreco@adelphia.net> wrote in message news:hMWdnandxfDPWdbbnZ2dnUVZ_o-knZ2d@adelphia.com...
> > 
> > I'm developer of the mpt fusion linux driver.  Mike, who at LSI told you
> > that you can't mix SAS/SATA drives on the 1068?  If your running mpt
> > fusion (not megaraid), you can mix SATA and SAS on a single controller 
> > as long as the devices are configured at single devices, non-raid.  If you
> > create a RAID volume, then it has to all SAS or SATA drives in that raid
> > volume.   Since we support two logical volumes, its possible to have one
> > raid volume as SATA, and the other as SAS.  
> > Here is a link to our website containing documentation on our products
> > 
> > http://www.lsi.com/storage_home/products_home/host_bus_adapters/sas_hbas/index.html
> > 
> > Eric Moore
> > LSI Corporation
> > Eric.Moore@lsi.com
> > 
> 
> Finally some first-hand information! Thanks for chiming in, Eric.

Unfortunately he didn't clear up the op's real point of concern at all:  
why "LSI" "warns against possible data inconsistencies/losses".

In other words will the controller/driver actually allow SAS and 
SATA drives in the same RAID volume when it really shouldn't?

A simple yes or no would have sufficed. Possibly accompanied 
by a firm "My colleague Mike at LSI, he was just plain wrong".

Now the question is still open.

> 
> Rob

> In other words will the controller/driver actually allow SAS and
> SATA drives in the same RAID volume when it really shouldn't?
>

Folkert - I will check with the firmware folks next Monday.   As long as I've worked on the project, I've been told raid volumes 
need to entirely SAS or SATA, not mixed.   I doubt it has anything to do with rotational speed as mentioned in some of this thread, 
but I will check.   I will reply with my findings next week.

Thanks,
Eric 

Eric Moore:
....
> > "Michael Giegerich" <migieger@web.de> wrote in message news:huit0f.kc32.ln@luva.dyndns.org
> >> LSI doesn't recommend this and warns against possible
> >> data inconsistencies/losses. No further reason given
> >> (or at least I didn't find it in their web pages).
....
> >> Nevertheless, did anybody out there try this? Results?
> 
> I'm developer of the mpt fusion linux driver.  Mike, who at LSI told you that you can't mix SAS/SATA drives on the 1068?    If your 
> running mpt fusion (not megaraid), you can mix SATA and SAS on a single controller as long as the devices are configured at single 
> devices, non-raid.  If you create a RAID volume, then it has to all SAS or SATA drives in that raid volume.   Since we support two 
> logical volumes, its possible to have one raid volume as SATA, and the other as SAS.  Here is a link to our website containing 
> documentation on our products

Great. Thanks a lot for this information.

I'll use FreeBSD's mpt fusion driver, thus I guess
two raid 1 arrays, one 2x SCSI and the other 2x
SATA, should work together well...

The warning I mentioned is indeed found in the
Embedded MegaRAID Software User's Guide Ver 1.0
(page 1-4).
I understand (now) that this is software and not
hardware (firmware) related.

> http://www.lsi.com/storage_home/products_home/host_bus_adapters/sas_hbas/index.html

I found a confirming information in the
"TECHNICAL MANUAL LSISAS1068 PCI-X to 8-Port
Serial Attached SCSI/SATA Controller" (Oct. 2005,
Ver. 2.1) that the LSISAS1068 "allows mixed
connections to SAS or SATA targets" (page 1-10).

As soon as I get hold of the 2 Seagate ST3500630NS,
I'll check for myself... (will report back)...

-- 
Michael Giegerich

"Michael Giegerich" <migieger@web.de> wrote in message news:ua1t2f.i5m.ln@luva.dyndns.org
> Eric Moore:
> ...
> > > "Michael Giegerich" <migieger@web.de> wrote in message news:huit0f.kc32.ln@luva.dyndns.org
> > > > LSI doesn't recommend this and warns against possible
> > > > data inconsistencies/losses. No further reason given
> > > > (or at least I didn't find it in their web pages).
> ...
> > > > Nevertheless, did anybody out there try this? Results?
> > 
> > I'm developer of the mpt fusion linux driver.  Mike, who at LSI told you that you can't mix SAS/SATA drives on the 1068?    If
> > your running mpt fusion (not megaraid), you can mix SATA and SAS on a single controller as long as the devices are configured
> > at single devices, non-raid.  If you create a RAID volume, then it has to all SAS or SATA drives in that raid volume.   Since
> > we support two logical volumes, its possible to have one raid volume as SATA, and the other as SAS.  Here is a link to our
> > website containing documentation on our products
> 
> Great. Thanks a lot for this information.
> 
> I'll use FreeBSD's mpt fusion driver, thus I guess
> two raid 1 arrays, one 2x SCSI and the other 2x
> SATA, should work together well...
> 
> The warning I mentioned is indeed found in the
> Embedded MegaRAID Software User's Guide Ver 1.0
> (page 1-4).

So this is a concealed warning that their software is broken,
as originally suggested.

> I understand (now) that this is software and not hardware 
> (firmware) related.

Minor difference, firmware is software also.
And embedded software is some kind of firmware too.

> 
> > http://www.lsi.com/storage_home/products_home/host_bus_adapters/sas_hbas/index.html
> 

> I found a confirming information in the
> "TECHNICAL MANUAL LSISAS1068 PCI-X to 8-Port
> Serial Attached SCSI/SATA Controller" (Oct. 2005,
> Ver. 2.1) that the LSISAS1068 "allows mixed
> connections to SAS or SATA targets" (page 1-10).

Can these people at LSI not even write one sentence without starting 
another confusion? : 'mixed' and 'or' are contradictory.

> 
> As soon as I get hold of the 2 Seagate ST3500630NS,
> I'll check for myself... (will report back)...

Check what?

"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message news:46536f64$0$97234>>
>> I'll use FreeBSD's mpt fusion driver, thus I guess
>> two raid 1 arrays, one 2x SCSI and the other 2x
>> SATA, should work together well...
>>
>> The warning I mentioned is indeed found in the
>> Embedded MegaRAID Software User's Guide Ver 1.0
>> (page 1-4).
>
> So this is a concealed warning that their software is broken,
> as originally suggested.

Folkert -  This is what I found out.  The reason why RAID volumes can't be mixed is due to the way bad block management is 
implemented between SCSI(SAS) and SATA is different.  For example,  in SCSI standards, there is automatic reassignment of bad blocks 
when an bad sector is encountered, whereas with SATA this is not specified in the standards, so firmware has to manually handle this 
by allocating space at the end of the drive for bad block table and free space for available sectors.   I guess there would be 
issues when there is a mirror, and a bad sector was encounterred when one drive was SATA, and the mirror was SAS..  Bad Block 
Management would be spelled out in the SCSI(SAS) standards are on www.t10.org.  Let me know if you need me to point out which spec 
to read.   The SATA standards can be found on www.t13.org, and https://www.sata-io.org/.   In addition, another reason, is we were 
forced to not mix SAS/SATA in RAID volumes from some of our big box customers, such as HP, Dell, and IBM.

>> I found a confirming information in the
>> "TECHNICAL MANUAL LSISAS1068 PCI-X to 8-Port
>> Serial Attached SCSI/SATA Controller" (Oct. 2005,
>> Ver. 2.1) that the LSISAS1068 "allows mixed
>> connections to SAS or SATA targets" (page 1-10).
>
> Can these people at LSI not even write one sentence without starting
> another confusion? : 'mixed' and 'or' are contradictory.
>

As long as the end devices are not members of the RAID volume, you can have a mix of SAS and SATA devices connected to the 
controller.   If your creating a RAID volume, they have to all the same.   Is that confusing or contradictory?

Eric

"Michael Giegerich" <migieger@web.de> wrote in message news:ua1t2f.i5m.ln@luva.dyndns.org...
> I'll use FreeBSD's mpt fusion driver, thus I guess
> two raid 1 arrays, one 2x SCSI and the other 2x
> SATA, should work together well...
>
> The warning I mentioned is indeed found in the
> Embedded MegaRAID Software User's Guide Ver 1.0
> (page 1-4).
> I understand (now) that this is software and not
> hardware (firmware) related.
>
>> http://www.lsi.com/storage_home/products_home/host_bus_adapters/sas_hbas/index.html


Micheal - I don't work on MegaRAID, that is a different product offering from LSI, you can find those controllers from this link 
http://www.lsi.com/storage_home/products_home/internal_raid/index.html.   That is a different division from the one I work in, also 
they have different device drivers as well.

What I work on is Standard Host Adapters, our cards have Integrated RAID,  with only RAID 0, 1, and IME.
MegaRAID will contain much more raid levels, for instance RAID 0, 1, 10, 5, 50, 6, and 60, and it will have memory slots wth battery 
backup.

"Eric Moore" <ericmooreco@adelphia.net> wrote in message news:AtmdnZjAVtbhncjbnZ2dnUVZ_jadnZ2d@adelphia.com
> "Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message news:46536f64$0$97234>>
> > > I'll use FreeBSD's mpt fusion driver, thus I guess
> > > two raid 1 arrays, one 2x SCSI and the other 2x
> > > SATA, should work together well...
> > >
> > > The warning I mentioned is indeed found in the
> > > Embedded MegaRAID Software User's Guide Ver 1.0
> > > (page 1-4).
> >
> > So this is a concealed warning that their software is broken,
> > as originally suggested.

> Folkert -  This is what I found out.

Gee wiz, no kidding.

> The reason why RAID volumes can't be mixed is due to the way bad block management is
> implemented between SCSI(SAS) and SATA is different.

Nope, it's not. They both have it.
The difference is that you can configure it on SCSI (including disabling
it) but not on (S)ATA.

> For example, in SCSI standards, there is automatic reassignment of bad blocks when an
> bad sector is encountered,

Wrong. You got it backwards. That's (S)ATA.
SCSI bad block management can be configured where (S)ATA can not (automatic).
So SCSI's auto bad block management can be switched off where SATA's can not.
In SCSI, near bad blocks can be forcibly reassigned where in (S)ATA it can not.

> whereas with SATA this is not specified in the standards,

Because there is nothing to specify, currently.
Maybe in future standards the need may grow for configurability of it.
Or add forced reassign.

> so firmware has to manually handle this by allocating space at the end of the drive for bad block table and free space for
available sectors.

That is utter crap.
That is what the antiquated RAID systems do for standard and which fails with SATA.
(Failure being relative when a perfectly good 'bad' block is set aside when it need not).

> I guess

Exactly!

> there would be issues when there is a mirror, and a bad sector was encounterred when one drive was SATA, and the mirror was SAS..

Not a problem if both do automatic reassignment. But not a problem either
if they don't. Just different ways of handinge it.
Auto bad block management didn't make a problem either with previous
methods of setting away bad sectors/clusters in filemanagement systems.
It can work perfectly side by side.
It has to because automatic reassignment doesn't work in all situations sin-
ce it works differently for reads and writes. It's not a perfect cure for all.

> Bad Block Management would be spelled out in the SCSI(SAS) standards are on www.t10.org.

> Let me know if you need me to point out which spec to read.

No thanks. But feel free to read them yourself sometimes.

> The SATA standards can be found on www.t13.org, and https://www.sata-io.org/.

> In addition, another reason, is we were forced to not mix SAS/SATA in RAID
> volumes from some of our big box customers, such as HP, Dell, and IBM.

And I can easily see why.

>
> > > I found a confirming information in the
> > > "TECHNICAL MANUAL LSISAS1068 PCI-X to 8-Port
> > > Serial Attached SCSI/SATA Controller" (Oct. 2005,
> > > Ver. 2.1) that the LSISAS1068 "allows mixed
> > > connections to SAS or SATA targets" (page 1-10).
> >
> > Can these people at LSI not even write one sentence without starting
> > another confusion? : 'mixed' and 'or' are contradictory.
> >
>
> As long as the end devices are not members of the RAID volume, you can have a mix of SAS and SATA devices connected to the
> controller.   If your creating a RAID volume, they have to all the same.

The sentence is what it is: 'mixed' and 'or' are contradictory.

> Is that confusing or contradictory?

Both, if the controller lets you mix them when it's not allowed.
Both, if the controller lets you mix them and an initially working combina-tion exists.
If not then the warning is obviously false since the situation cannot exist
and no harm is done.

>
> Eric

"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message news:465625c5$1$97234$892e7fe2@authen.yellow.readfreenews.net...

Look smart ass,  do you really care to have an answer to your question, or do you want to talk a bunch of smack?

In SPC-4 section 6.3.5, is the Read-Write Error Recovery mode page, you can enable/disable automatic reallocation of defective 
logical via the AWRE and ARRE bits.  When these bits are set to zero, then reassignment can only occur via REASSIGN_BLOCKS (SPC-4 
Section 5.18).   If REASSIGN_BLOCK fails, you will get a CHECK_CONDITION and corresponding sense data would provide info on the 
unrecoverable logical block.   There are four sources of defect information, PLIST, CLIST, DLIST, and GLIST.

Just looking at SATL-2 spec, the Read-Write Error Recovery has both AWRE and ARRE bits set to one, and there is no REASSIGN_BLOCK, 
hence auto reassignment of blocks is always enabled.

The person I spoke to yesterday told me the bad block management scheme is different between SATA and SAS,  and that is why they 
don't want to mix it in a RAID1 volume.   I didn't get much more specifics than that.

Five years ago I was working on a MegaRAID ATA Software RAID drivers, and we implemented bad block maangment in the driver since at 
the time drive manufactures were not implementing automatic reassignment of defective blocks, so that is where I got my guess from. 
Obviously as you stated in the other email, that is no longer the case.

Do you have other questions, or is that is?

Eric

"Eric Moore" <ericmooreco@adelphia.net> wrote in message news:rcmdnQLuT69MyMvbnZ2dnUVZ_segnZ2d@adelphia.com
> "Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message news:465625c5$1$97234$892e7fe2@authen.yellow.readfreenews.net...

> *Look smart ass,*

Look who's talking. We aren't shouting, are we, Mr. Moore?
And snipping all I said -what you now confirm- is purely coincidental, right?
You're not trying to fool someone.

Thanks for confirming that I was right and you were wrong.
Pity then that you are not professional enough to actually admit it and 
apologize for it.
I'll assume that your name is likely not Eric Moore either, unless you
are actually that stupid to call someone a "smartass" when posting as 
an employee of LSI corporation.

> do you really care to have an answer to your question,

What question would that be, you must confuse me for someone else.

> or do you want to talk a bunch of smack?

Nope, I'll leave that to you. You appear to be quite good at it.
Too bad for you that not all people here are as gullible as you think.

>
> In SPC-4 section 6.3.5, is the Read-Write Error Recovery mode page, you can enable/disable automatic reallocation of defective
> logical via the AWRE and ARRE bits.  

> When these bits are set to zero, then reassignment can only occur via REASSIGN_BLOCKS (SPC-4 Section 5.18).   

See, what you don't learn, when you follow your own advice.
Pity then that that wasn't new to me and confirms exactly what I said.

> If REASSIGN_BLOCK fails, you will get a CHECK_CONDITION and corresponding sense data would provide info on the
> unrecoverable logical block.   

If a Reassign Blocks fails it means that the drive is toast.
The info on the unrecoverable block won't do you any good, since 
you already know that it is bad, why else would you reassign it.
You would also get this info if the drive was on automatic.

You don't need this particular scheme to know that a drive is toast.
If a 'bad' sector stays bad on a (S)ATA drive after that sector has been 
overwritten (effectively causing a REASSIGN BLOCKS) then you have 
the same effective situation as with SCSI/SAS.

The only extra value REASSIGN BLOCKS has is that you can reassign 
blocks that are slow in reading on SCSI/SAS where you can't with SATA.

> There are four sources of defect information, PLIST, CLIST, DLIST, and GLIST.

Who cares. Trying to impress someone, Mr. Moore? It's not working.
You are just making more fool of yourself. 
The only list affected by the Reassign Blocks command is the GLIST.

C and D list are input lists to the Format Unit command and are added 
to the GLIST at completion of that command.

None of the lists have any relevance to the availability of the logical 
block numbers that are in them other than that these blocks are not in 
or are about to be moved from the expected original physical location.

>
> Just looking at SATL-2 spec,

Presumably you mean SAT-2, SCSI to ATA translation rev. 2,
which covers SATL (logical or physical) devices.

This has nothing to do with what ATA disk drives themselves can or can't do.

> the Read-Write Error Recovery has both AWRE and ARRE bits set to one,

Not according to SAT-2. AWRE is set, ARRE is not.

> and there is no REASSIGN_BLOCK,

Yup, exactly as I said.

> hence auto reassignment of blocks is always enabled.

Which is a bad thing?
I have no idea where that conclusion comes from, especially since ARRE is off.

And in SATL these are merely indicators, read only, status bits, 
they don't necessarily tell what the SATL device (including the 
(S)ATA device) is or isn't doing, or is capable of. They're fake.
Which is likely it's weak point.

> The person I spoke to yesterday told me the bad block management scheme is different,  

Du-uh ! Because of the reasons you just described above.

> between SATA and SAS

Presumably you mean: how LSI manages it (between SATA and SAS),
not how SATA and SCSI/SAS drives manage it internally.

> and that is why they don't want to mix it in a RAID1 volume.

Like I said. And it has nothing to do with RAID1 specifically.

> I didn't get much more specifics than that.

Exactly.
Because it's antiquated what they do and who wants to admit to that.

>
> Five years ago I was working on a MegaRAID ATA Software RAID drivers, and we implemented bad block maangment in the driver 

> since at the time drive manufactures were not implementing automatic reassignment of defective blocks, 

Care to mention one model of that time that didn't implement it? No? 
Didn't think so.
I have IBM drive manuals going back to 1998 that mention auto reassign.
Going even back to 1994 stating :
"Transparent defect management by Automatic Defect Reallocation during 
Write Cache"

And how would automatic reassignment have been helpful then, where just 
a few paragraphs above you gave the impression how it was unhelpful. 
Sounds like you can't make up your mind. 
You wouldn't be just blowing smoke, would you, Mr. Moore?

> so that is where I got my guess from.

I used "antiquated" for a reason.

> Obviously as you stated in the other email, 

Email huh. You are that fresh to newsnet, are ya.

> that is no longer the case.

> Do you have other questions, or is that is?

Try and learn to read. I didn't have a question. 
That was Michael, the person who's name you misspelled, twice.

Next time, try not to educate people that obviously know more than you do. 
It's usually not appreciated, especially when you are new to a group.

>
> Eric

"Eric Moore" <ericmooreco@adelphia.net> wrote in message 
news:rcmdnQLuT69MyMvbnZ2dnUVZ_segnZ2d@adelphia.com...
> Look smart ass,  do you really care to have an answer to your question, or 
> do you want to talk a bunch of smack?
>

Eric,

Do yourself a favor and put Mr. Rienstra in your *ploink* filter. He does 
have detailed knowlegde about SCSI but over the years he has demonstrated 
that he takes pride in using those skills only to ridicule anyone who puts a 
comma in the wrong spot. I've only sporadically caught him on an actual 
helpful response. He has the human interaction skills of a brick. I guess 
it's part of a severe personality disorder of some kind. Anyway, it's better 
for everyone to just ignore this sorry guy.

Rob

Michael Giegerich:

[ Lot of stuff about do and don't mix SAS and SATA
  drives on LSILOGIC 1068 ]

> As soon as I get hold of the 2 Seagate ST3500630NS,
> I'll check for myself... (will report back)...

Well, the SATA drives are indeed running with SAS
drives on a LSILOGIC 1068...

My setup:

- Mobo with LSILOGIC 1068 (FSC Primergy TX150S5)
- Backplane
- 2 Fujitsu MAX3073RC as raid 1 array
- 2 Seagate ST3500630NS as raid 1 array


The dmesg output for reference:

Copyright (c) 1992-2007 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 6.2-RELEASE-p5 #2: Fri Jun  1 19:37:05 CEST 2007
    root@test.home:/usr/obj/usr/src/sys/LOCAL
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(R) CPU            3050  @ 2.13GHz (2128.07-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x6f6  Stepping = 6
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0xe3bd<SSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,<b9>,CX16,<b14>,<b15>>
  AMD Features=0x20100000<NX,LM>
  AMD Features2=0x1<LAHF>
  Cores per package: 2
real memory  = 2146304000 (2046 MB)
avail memory = 2095194112 (1998 MB)
ACPI APIC Table: <FSC    	 APIC  >
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0 <Version 2.0> irqs 0-23 on motherboard
ioapic1 <Version 2.0> irqs 24-47 on motherboard
kbd1 at kbdmux0
ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
acpi0: <PTLTD 	 XSDT> on motherboard
acpi0: Power Button (fixed)
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0xf008-0xf00b on acpi0
cpu0: <ACPI CPU> on acpi0
acpi_perf0: <ACPI CPU Frequency Control> on cpu0
acpi_perf0: failed in PERF_STATUS attach
device_attach: acpi_perf0 attach returned 6
acpi_perf0: <ACPI CPU Frequency Control> on cpu0
acpi_perf0: failed in PERF_STATUS attach
device_attach: acpi_perf0 attach returned 6
cpu1: <ACPI CPU> on acpi0
acpi_perf1: <ACPI CPU Frequency Control> on cpu1
acpi_perf1: failed in PERF_STATUS attach
device_attach: acpi_perf1 attach returned 6
acpi_perf1: <ACPI CPU Frequency Control> on cpu1
acpi_perf1: failed in PERF_STATUS attach
device_attach: acpi_perf1 attach returned 6
acpi_button0: <Power Button> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> irq 16 at device 1.0 on pci0
pci1: <ACPI PCI bus> on pcib1
pcib2: <ACPI PCI-PCI bridge> at device 0.0 on pci1
pci2: <ACPI PCI bus> on pcib2
mpt0: <LSILogic SAS/SATA Adapter> port 0x4000-0x40ff mem 0xfd110000-0xfd113fff,0xfd100000-0xfd10ffff irq 25 at device 5.0 on pci2
mpt0: [GIANT-LOCKED]
mpt0: MPI Version=1.5.13.0
mpt0: mpt_cam_event: 0x16
mpt0: Unhandled Event Notify Frame. Event 0x16 (ACK not required).
mpt0: mpt_cam_event: 0x12
mpt0: Unhandled Event Notify Frame. Event 0x12 (ACK not required).
mpt0: mpt_cam_event: 0x12
mpt0: Unhandled Event Notify Frame. Event 0x12 (ACK not required).
mpt0: mpt_cam_event: 0x12
mpt0: Unhandled Event Notify Frame. Event 0x12 (ACK not required).
mpt0: mpt_cam_event: 0x12
mpt0: Unhandled Event Notify Frame. Event 0x12 (ACK not required).
mpt0: mpt_cam_event: 0x16
mpt0: Unhandled Event Notify Frame. Event 0x16 (ACK not required).
mpt0: mpt_cam_event: 0xb
mpt0: Unhandled Event Notify Frame. Event 0xb (ACK not required).
mpt0: mpt_cam_event: 0xb
mpt0: Unhandled Event Notify Frame. Event 0xb (ACK not required).
mpt0: mpt_cam_event: 0x21
mpt0: Unhandled Event Notify Frame. Event 0x21 (ACK not required).
mpt0: mpt_cam_event: 0x21
mpt0: Unhandled Event Notify Frame. Event 0x21 (ACK not required).
pcib3: <ACPI PCI-PCI bridge> irq 17 at device 28.0 on pci0
pci7: <ACPI PCI bus> on pcib3
pcib4: <ACPI PCI-PCI bridge> irq 17 at device 28.4 on pci0
pci13: <ACPI PCI bus> on pcib4
bge0: <Broadcom BCM5750 C1, ASIC rev. 0x4201> mem 0xfd300000-0xfd30ffff irq 16 at device 0.0 on pci13
miibus0: <MII bus> on bge0
brgphy0: <BCM5750 10/100/1000baseTX PHY> on miibus0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto
bge0: Ethernet address: 00:30:05:cd:da:25
pcib5: <ACPI PCI-PCI bridge> irq 16 at device 28.5 on pci0
pci14: <ACPI PCI bus> on pcib5
uhci0: <UHCI (generic) USB controller> port 0x2000-0x201f irq 23 at device 29.0 on pci0
uhci0: [GIANT-LOCKED]
usb0: <UHCI (generic) USB controller> on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1: <UHCI (generic) USB controller> port 0x2400-0x241f irq 22 at device 29.1 on pci0
uhci1: [GIANT-LOCKED]
usb1: <UHCI (generic) USB controller> on uhci1
usb1: USB revision 1.0
uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2: <UHCI (generic) USB controller> port 0x2800-0x281f irq 21 at device 29.2 on pci0
uhci2: [GIANT-LOCKED]
usb2: <UHCI (generic) USB controller> on uhci2
usb2: USB revision 1.0
uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
uhci3: <UHCI (generic) USB controller> port 0x2c00-0x2c1f irq 20 at device 29.3 on pci0
uhci3: [GIANT-LOCKED]
usb3: <UHCI (generic) USB controller> on uhci3
usb3: USB revision 1.0
uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub3: 2 ports with 2 removable, self powered
ehci0: <Intel 82801GB/R (ICH7) USB 2.0 controller> mem 0xfd000000-0xfd0003ff irq 23 at device 29.7 on pci0
ehci0: [GIANT-LOCKED]
usb4: EHCI version 1.0
usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3
usb4: <Intel 82801GB/R (ICH7) USB 2.0 controller> on ehci0
usb4: USB revision 2.0
uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub4: 8 ports with 8 removable, self powered
pcib6: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pci20: <ACPI PCI bus> on pcib6
pci20: <display, VGA> at device 3.0 (no driver attached)
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel ICH7 UDMA100 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x3420-0x342f at device 31.1 on pci0
ata0: <ATA channel 0> on atapci0
ata1: <ATA channel 1> on atapci0
atapci1: <Intel ICH7 SATA300 controller> port 0x3440-0x3447,0x3434-0x3437,0x3438-0x343f,0x3430-0x3433,0x3400-0x341f mem 0xfd000400-0xfd0007ff irq 19 at device 31.2 on pci0
atapci1: AHCI Version 01.10 controller with 4 ports detected
ata2: <ATA channel 0> on atapci1
ata3: <ATA channel 1> on atapci1
ata4: <ATA channel 2> on atapci1
ata5: <ATA channel 3> on atapci1
pci0: <serial bus, SMBus> at device 31.3 (no driver attached)
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: model IntelliMouse, device ID 3
fdc0: <floppy drive controller> port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fdc0: [FAST]
ppc0: <Standard parallel printer port> port 0x378-0x37b irq 7 on acpi0
ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
ppbus0: <Parallel port bus> on ppc0
plip0: <PLIP network interface> on ppbus0
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A
sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
pmtimer0 on isa0
orm0: <ISA Option ROM> at iomem 0xc0000-0xc7fff on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
Timecounters tick every 1.000 msec
acd0: DVDROM <HL-DT-STDVD-ROM GDR8164B/0F08> at ata0-master UDMA33
da0 at mpt0 bus 0 target 0 lun 0
da0: <LSILOGIC Logical Volume 3000> Fixed Direct Access SCSI-2 device 
da0: 300.000MB/s transfers, Tagged Queueing Enabled
da0: 69618MB (142577664 512 byte sectors: 255H 63S/T 8875C)
da1 at mpt0 bus 0 target 2 lun 0
da1: <LSILOGIC Logical Volume 3000> Fixed Direct Access SCSI-2 device 
da1: 300.000MB/s transfers, Tagged Queueing Enabled
da1: 476837MB (976562176 512 byte sectors: 255H 63S/T 60788C)
SMP: AP CPU #1 Launched!
Trying to mount root from ufs:/dev/da0s2a
bge0: link state changed to DOWN
bge0: link state changed to UP

-- 
Michael Giegerich

"Michael Giegerich" <migieger@web.de> wrote in message news:bror3f.gga2.ln@luva.dyndns.org
> Michael Giegerich:
> 
> [ Lot of stuff about do and don't mix SAS and SATA
>   drives on LSILOGIC 1068 ]
> 
> > As soon as I get hold of the 2 Seagate ST3500630NS,
> > I'll check for myself... (will report back)...

> Well, the SATA drives are indeed running with SAS
> drives on a LSILOGIC 1068...

I didn't think that was ever in doubt (with those with a clue, that is).
There isn't much market for a controller that can only function as a 
SAS controller or a SATA controller, one at a time.

So the question still is: will it let you mix SAS and SATA within arrays.
Whether that is the setup utility allowing it or the driver, once setup.
This only will determine whether there was some truth to the warning or 
that it was completely bogus and unnecessarily confusing potential users.

> 
> My setup:
> 
> - Mobo with LSILOGIC 1068 (FSC Primergy TX150S5)
> - Backplane
> - 2 Fujitsu MAX3073RC as raid 1 array
> - 2 Seagate ST3500630NS as raid 1 array
> 
> 
> The dmesg output for reference:
> 

crap deleted.

> So the question still is: will it let you mix SAS and SATA within arrays.
> Whether that is the setup utility allowing it or the driver, once setup.
> This only will determine whether there was some truth to the warning or
> that it was completely bogus and unnecessarily confusing potential users.

Hi Folkert,

My SCSI experience isn't relatively significant or extensive (I'm sure you 
will confirm ;-) but I was under the impression that if you didn't use all 
the same brand, model, size, speed, etc drives in an array that you were 
asking for problems. Is that old news, only for certain types of arrays 
or???

Every time I read about combining SAS and SATA drives into the same array it 
sounds 'wrong' to me.

Any edjumacation appreciated.

-- 
John L Rice
my subconscious makes a conscientious effort to get my conscious mind 
farting unconscionably 

"John L Rice" <Drummer@ImJohn.com> wrote in message news:1369q5nror6643c@corp.supernews.com
> > So the question still is: will it let you mix SAS and SATA within arrays.
> > Whether that is the setup utility allowing it or the driver, once setup.
> > This only will determine whether there was some truth to the warning or
> > that it was completely bogus and unnecessarily confusing potential users.
>
> Hi Folkert,
>
> My SCSI experience isn't relatively significant or extensive (I'm sure you
> will confirm ;-) 

> but I was under the impression that if you didn't use all the same brand, 
> model, size, speed, etc drives in an array that you were asking for problems.
> Is that old news, only for certain types of arrays or???

Impression is probably the correct word to use. Or "best known secret".
Anecdotal preconditioning, opinions, whatever vagueness you can come up with.

My personal 'impression' is that this has to do with access optimization,
where spindle sync is used and/or specific modepages set to specific
values, e.g. number of cachesegments set to specific values on all drives.
Any differences between drive makes would probably defeat those efforts.

>
> Every time I read about combining SAS and SATA drives into the same array it
> sounds 'wrong' to me.

Yes, but you can't really put a finger on it, right?
I've just been going through a users reference manaual describing a 
range of serveRaids and I couldn't find anything about it other than
'appropriate size' for a "standby hot spare" and "Creates arrays 
by grouping together 'same-sized' physical drives" under "Express
Configuration". If there are very thight requirements you wouldn't 
know them from reading the manual.

>
> Any edjumacation appreciated.

RAID should only be about striping and mirroring sectors 
whether that is on a logical (driver) or physical (drive) level.
It shouldn't matter what type of drive the sectors reside on.

And isn't that what OS supported RAID (no RAID controller 
involvement whatsoever) is anyway? Why should it be any different 
for hardware or firmware supported RAID.
If it's a mix of drives then performance will be a function of the mix.
*So what, big deal.*

"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message 
news:4665f8e0$0$97270$892e7fe2@authen.yellow.readfreenews.net...
> "John L Rice" <Drummer@ImJohn.com> wrote in message 
> news:1369q5nror6643c@corp.supernews.com
>> > So the question still is: will it let you mix SAS and SATA within 
>> > arrays.
>> > Whether that is the setup utility allowing it or the driver, once 
>> > setup.
>> > This only will determine whether there was some truth to the warning or
>> > that it was completely bogus and unnecessarily confusing potential 
>> > users.
>>
>> Hi Folkert,
>>
>> My SCSI experience isn't relatively significant or extensive (I'm sure 
>> you
>> will confirm ;-)
>
>> but I was under the impression that if you didn't use all the same brand,
>> model, size, speed, etc drives in an array that you were asking for 
>> problems.
>> Is that old news, only for certain types of arrays or???
>
> Impression is probably the correct word to use. Or "best known secret".
> Anecdotal preconditioning, opinions, whatever vagueness you can come up 
> with.
>
> My personal 'impression' is that this has to do with access optimization,
> where spindle sync is used and/or specific modepages set to specific
> values, e.g. number of cachesegments set to specific values on all drives.
> Any differences between drive makes would probably defeat those efforts.
>
>>
>> Every time I read about combining SAS and SATA drives into the same array 
>> it
>> sounds 'wrong' to me.
>
> Yes, but you can't really put a finger on it, right?
> I've just been going through a users reference manaual describing a
> range of serveRaids and I couldn't find anything about it other than
> 'appropriate size' for a "standby hot spare" and "Creates arrays
> by grouping together 'same-sized' physical drives" under "Express
> Configuration". If there are very thight requirements you wouldn't
> know them from reading the manual.
>
>>
>> Any edjumacation appreciated.
>
> RAID should only be about striping and mirroring sectors
> whether that is on a logical (driver) or physical (drive) level.
> It shouldn't matter what type of drive the sectors reside on.
>
> And isn't that what OS supported RAID (no RAID controller
> involvement whatsoever) is anyway? Why should it be any different
> for hardware or firmware supported RAID.
> If it's a mix of drives then performance will be a function of the mix.
> *So what, big deal.*

Thanks for the info, Folkert!

Maybe I'm thinking about a time 10 years ago or so where I needed to replace 
a drive that died in an array and there was something I read somewhere about 
making sure it was the same size and  . .well . . .my memory on it is so 
fuzzy I'm not sure if I'm remembering stuff or making up stuff that would 
make sense! ;-)

John 

"Rob Turk" <wipe_this_r.turk@chello.nl> wrote in message news:7cea7$465e867a$4df850e0$14831@news.chello.nl...
> "Eric Moore" <ericmooreco@adelphia.net> wrote in message news:rcmdnQLuT69MyMvbnZ2dnUVZ_segnZ2d@adelphia.com...
>> Look smart ass,  do you really care to have an answer to your question, or do you want to talk a bunch of smack?
>>
>
> Eric,
>
> Do yourself a favor and put Mr. Rienstra in your *ploink* filter. He does have detailed knowlegde about SCSI but over the years he 
> has demonstrated that he takes pride in using those skills only to ridicule anyone who puts a comma in the wrong spot. I've only 
> sporadically caught him on an actual helpful response. He has the human interaction skills of a brick. I guess it's part of a 
> severe personality disorder of some kind. Anyway, it's better for everyone to just ignore this sorry guy.
>
> Rob
>
>

Thanks for the advice. This guy is the resident list expert, and everybody else is stupid.  He apparently has all the inside 
information why volumes can't be mixed with SATA./SAS.

The information I was providing was from an firmware architect at LSI.   I wasn't providing any false information.  The mpt fusion 
RAID implementation is done from firmware,  so its hidden from the operating system and device drivers.   In the device drivers, 
everything appears as a scsi device, and the upper layers have no knowledge that the underlying device is SATA or SAS, or RAID 
device.  So the reason why SATA and SAS can't be mixed in a RAID volume would not be apparent in the device driver, only the 
firmware would know, hence why I asked someone from the firmware group why  they can't be mixed.. I do infact work at LSI, and 
maintain the linux drivers.  You would be able to find my posts to linux scsi mailing list by googling for eric.moore@lsi.com. 
Apparently Mr. Rienstra  has pointed out how dumb I am...  There's really no reason to waste any time contributing here since he has 
all the explanations why this product is working the way it is.

Eric

Folkert Rienstra:
> "Michael Giegerich" <migieger@web.de> wrote in message news:bror3f.gga2.ln@luva.dyndns.org
> > Michael Giegerich:
> > 
> > [ Lot of stuff about do and don't mix SAS and SATA
> >   drives on LSILOGIC 1068 ]
> > 
> > > As soon as I get hold of the 2 Seagate ST3500630NS,
> > > I'll check for myself... (will report back)...
> 
> > Well, the SATA drives are indeed running with SAS
> > drives on a LSILOGIC 1068...
> 
> I didn't think that was ever in doubt (with those with a clue, that is).
> There isn't much market for a controller that can only function as a 
> SAS controller or a SATA controller, one at a time.
> 
> So the question still is: will it let you mix SAS and SATA within arrays.

As I wanted raid 1 setups (with identical drives
obviously), this question wasn't important to me.

Thanks to Eric Moore I'm actually happy.

-- 
Michael Giegerich

"Michael Giegerich" <migieger@web.de> wrote in message news:0ksi1f.2e31.ln@luva.dyndns.org
> John L Rice:
> > > "Michael Giegerich" migieger@web.de> wrote in message news:huit0f.kc32.ln@luva.dyndns.org...
> > > 
> > > LSI doesn't recommend this and warns against possible
> > > data inconsistencies/losses. No further reason given
> > > (or at least I didn't find it in their web pages).

> > How was it worded? 

Easy enough question. 
So why was there no answer? Because the issue never existed.

> > Were they just warning people not to do something
> > obviously dumb like combining SAS and SATA drives into the same array?

> > If they are saying not to have a SAS array and a separate SATA array 
> > on the same controller then I agree with Frank

> This one.

Uhuh. Care to point out where they say that?

Obviously the reference that you gave (but failed to link or quote, one 
now wondesr why) -further up in the thread- doesn't say that at all.

"Michael Giegerich" <migieger@web.de> wrote in message news:ua1t2f.i5m.ln@luva.dyndns.org
> Eric Moore:
> ...
> > > "Michael Giegerich" <migieger@web.de> wrote in message news:huit0f.kc32.ln@luva.dyndns.org
> > > > LSI doesn't recommend this and warns against possible
> > > > data inconsistencies/losses. No further reason given
> > > > (or at least I didn't find it in their web pages).
> ...
> > > > Nevertheless, did anybody out there try this? Results?
> > 
> > I'm developer of the mpt fusion linux driver.  Mike, who at LSI told you that you can't mix SAS/SATA drives on the 1068?    If
> > your running mpt fusion (not megaraid), you can mix SATA and SAS on a single controller as long as the devices are configured
> > at single devices, non-raid.  If you create a RAID volume, then it has to all SAS or SATA drives in that raid volume.   Since
> > we support two logical volumes, its possible to have one raid volume as SATA, and the other as SAS.  Here is a link to our
> > website containing documentation on our products

> Great. Thanks a lot for this information.

As if you didn't already have it.

> 
> I'll use FreeBSD's mpt fusion driver, thus I guess  two raid 1 arrays, 
> one 2x SCSI and the other 2x SATA, should work together well...

> The warning I mentioned is indeed found 

So where did you find it first then?

> in the Embedded MegaRAID Software User's Guide Ver 1.0

Ok, so I searched for that again, globally this time, and finally found it.
http://manuals.fujitsu-siemens.com/serverbooks/content/manuals/english/lsi/lsi_emb-mraid-ug-en.pdf

> (page 1-4).

" LSI recommends that you do not use both SAS and SATA
drives *in the same array*."

Obviously this can't have been the warning that you were questioning
since with your intended use of seperate arrays it's blatantly obviously 
that this doesn't apply to you.

> I understand (now) that this is software and not hardware (firmware) related.
> 
> > http://www.lsi.com/storage_home/products_home/host_bus_adapters/sas_hbas/index.html

> I found a confirming information 

Confirming what exactly (since it says nothing about arrays)?

> in the "TECHNICAL MANUAL LSISAS1068 PCI-X to 8-Port Serial 
> Attached SCSI/SATA Controller" (Oct. 2005, Ver. 2.1)  that the LSISAS
> 1068 "allows mixed connections to SAS or SATA targets" (page 1-10).

Confirms absolutely nothing at all.
(Unless of course you haven't got a clue what 
the heck a "SCSI/SATA Controller" must be).

> 
> As soon as I get hold of the 2 Seagate ST3500630NS,
> I'll check for myself... (will report back)...

"Michael Giegerich" <migieger@web.de> wrote in message news:g8de4f.fiv.ln@luva.dyndns.org
> Folkert Rienstra:
> > "Michael Giegerich" <migieger@web.de> wrote in message news:bror3f.gga2.ln@luva.dyndns.org
> > > Michael Giegerich:
> > > 
> > > [ Lot of stuff about do and don't mix SAS and SATA
> > >   drives on LSILOGIC 1068 ]
> > > 
> > > > As soon as I get hold of the 2 Seagate ST3500630NS,
> > > > I'll check for myself... (will report back)...
> > 
> > > Well, the SATA drives are indeed running with SAS
> > > drives on a LSILOGIC 1068...
> > 
> > I didn't think that was ever in doubt (with those with a clue, that is).
> > There isn't much market for a controller that can only function as a
> > SAS controller or a SATA controller, one at a time.
> > 
> > So the question still is: will it let you mix SAS and SATA within arrays.

> As I wanted raid 1 setups (with identical drives

> obviously), 

Obviously, huh?

> this question wasn't important to me.

As it turns out you didn't even have a question to begin with.
Given the actual warning that you pointed out earlier on and your 
now stated usage intention there wasn't any problem from the start.
You just created a row over nothing. You made it all up. It's a troll.
No wonder this thread grew so big.

> 
> Thanks to Eric Moore I'm actually happy.

Yes, where would braindead people like yourself be without the Eric 
Moores, your new found messiahs. Pity he has barely a clue himself.

hey volkiff ,

dein delirium dauerte dieses mal wohl etwas laenger - es war so ruhig 
hier .

In article <4679b1ef$0$97252$892e7fe2@authen.yellow.readfreenews.net>, 
see_reply-to@myweb.nl says...
> "Michael Giegerich" <migieger@web.de> wrote in message news:g8de4f.fiv.ln@luva.dyndns.org
> > Folkert Rienstra:
> > > "Michael Giegerich" <migieger@web.de> wrote in message news:bror3f.gga2.ln@luva.dyndns.org
> > > > Michael Giegerich:
> > > > 
> > > > [ Lot of stuff about do and don't mix SAS and SATA
> > > >   drives on LSILOGIC 1068 ]
> > > > 
> > > > > As soon as I get hold of the 2 Seagate ST3500630NS,
> > > > > I'll check for myself... (will report back)...
> > > 
> > > > Well, the SATA drives are indeed running with SAS
> > > > drives on a LSILOGIC 1068...
> > > 
> > > I didn't think that was ever in doubt (with those with a clue, that is).
> > > There isn't much market for a controller that can only function as a
> > > SAS controller or a SATA controller, one at a time.
> > > 
> > > So the question still is: will it let you mix SAS and SATA within arrays.
> 
> > As I wanted raid 1 setups (with identical drives
> 
> > obviously), 
> 
> Obviously, huh?
> 
> > this question wasn't important to me.
> 
> As it turns out you didn't even have a question to begin with.
> Given the actual warning that you pointed out earlier on and your 
> now stated usage intention there wasn't any problem from the start.
> You just created a row over nothing. You made it all up. It's a troll.
> No wonder this thread grew so big.
> 
> > 
> > Thanks to Eric Moore I'm actually happy.
> 
> Yes, where would braindead people like yourself be without the Eric 
> Moores, your new found messiahs. Pity he has barely a clue himself.
> 

-- 
gravity is still active 
-<--@
gruss , wolfgang

wolfgang schneider <schnusi@gmx.net> writes:
>hey volkiff ,
>
>dein delirium dauerte dieses mal wohl etwas laenger - es war so ruhig 
>hier .
Wolfgang,

Kommt er nicht aus die Niederlande?  Kann er Deutsch sprechen?

Ich stimme mit Ihrer Aussage, jedoch �berein.

scott

"Scott Lurndal" <scott@slp53.sl.home> wrote in message news:fLyei.450$K44.417@newssvr13.news.prodigy.net
> wolfgang schneider <schnusi@gmx.net> writes:
> > hey volkiff ,
> >
> > dein delirium dauerte dieses mal wohl etwas laenger - es war so ruhig
> > hier .
> Wolfgang,

> Kommt er nicht aus die Niederlande?

> Kann er Deutsch sprechen?

Erstmal mein vater's Fahrrad zurueck!  How's that.

>
> Ich stimme mit Ihrer Aussage, jedoch �berein.

You compare with his stupid statement? If you say so.

>
> scott

hi scott ,

i don't know but he must be clever enough , so he easily should be able=20
to identify this sentence and blow back ....=20

In article <fLyei.450$K44.417@newssvr13.news.prodigy.net>,=20
scott@slp53.sl.home says...
> wolfgang schneider <schnusi@gmx.net> writes:
> >hey volkiff ,
> >
> >dein delirium dauerte dieses mal wohl etwas laenger - es war so ruhig=20
> >hier .
> Wolfgang,
>=20
> Kommt er nicht aus die Niederlande?  Kann er Deutsch sprechen?
>=20
> Ich stimme mit Ihrer Aussage, jedoch =FCberein.
>=20
> scott
>=20

--=20
gravity is still active=20
-<--@
gruss , wolfgang