|
|
|
|
| Author |
Message |
Eric Moore
Guest
|
 Posted: Thu May 24, 2007 8:04 am Post subject: Re: SAS and SATA (arrays) on one controller (LSISAS1068)? |
 |
|
"Michael Giegerich" <migieger@web.de> wrote in message news:ua1t2f.i5m.ln@luva.dyndns.org...
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. |
|
| Back to top |
|
 |
|
|
Folkert Rienstra
Guest
|
| Posted: Fri May 25, 2007 2:27 am Post subject: Re: SAS and SATA (arrays) on one controller (LSISAS1068)? |
|
|
"Eric Moore" <ericmooreco@adelphia.net> wrote in message news:AtmdnZjAVtbhncjbnZ2dnUVZ_jadnZ2d@adelphia.com
| Quote: | "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.
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
| Quote: | 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).
Exactly!
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
| Quote: |
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.
| Quote: | 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.
|
|
| Back to top |
|
|
Eric Moore
Guest
|
| Posted: Fri May 25, 2007 8:21 am Post subject: Re: SAS and SATA (arrays) on one controller (LSISAS1068)? |
|
|
"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message news:465625c5$1$97234$892e7fe2@authen.yellow.readfreenews.net...
Look smart ***, 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 |
|
| Back to top |
|
|
Folkert Rienstra
Guest
|
| Posted: Thu May 31, 2007 2:59 am Post subject: Re: SAS and SATA (arrays) on one controller (LSISAS1068)? |
|
|
"Eric Moore" <ericmooreco@adelphia.net> wrote in message news:rcmdnQLuT69MyMvbnZ2dnUVZ_segnZ2d@adelphia.com
| Quote: | "Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message news:465625c5$1$97234$892e7fe2@authen.yellow.readfreenews.net...
*Look smart ***,*
|
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.
| Quote: | do you really care to have an answer to your question,
|
What question would that be, you must confuse me for someone else.
| Quote: | 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.
| Quote: |
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.
| Quote: | 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.
| Quote: | 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.
| Quote: |
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.
| Quote: | 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.
| Quote: | and there is no REASSIGN_BLOCK,
|
Yup, exactly as I said.
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
| Quote: | I didn't get much more specifics than that.
|
Exactly.
Because it's antiquated what they do and who wants to admit to that.
| Quote: |
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?
| Quote: | so that is where I got my guess from.
|
I used "antiquated" for a reason.
| Quote: | Obviously as you stated in the other email,
|
Email huh. You are that fresh to newsnet, are ya.
| Quote: | 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.
|
|
| Back to top |
|
|
Rob Turk
Guest
|
| Posted: Thu May 31, 2007 1:22 pm Post subject: Re: SAS and SATA (arrays) on one controller (LSISAS1068)? |
|
|
"Eric Moore" <ericmooreco@adelphia.net> wrote in message
news:rcmdnQLuT69MyMvbnZ2dnUVZ_segnZ2d@adelphia.com...
| Quote: | Look smart ***, 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 |
|
| Back to top |
|
|
Fix your Windows Problems - FAST.
FREE Safe Scan Registry Check. Locate & Fix Errors in Minutes!
|
|
Michael Giegerich
Guest
|
| Posted: Sat Jun 02, 2007 3:18 pm Post subject: Re: SAS and SATA (arrays) on one controller (LSISAS1068)? |
|
|
Michael Giegerich:
[ Lot of stuff about do and don't mix SAS and SATA
drives on LSILOGIC 1068 ]
| Quote: | 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 |
|
| Back to top |
|
|
Folkert Rienstra
Guest
|
| Posted: Mon Jun 04, 2007 9:36 pm Post subject: Re: SAS and SATA (arrays) on one controller (LSISAS1068)? |
|
|
"Michael Giegerich" <migieger@web.de> wrote in message news:bror3f.gga2.ln@luva.dyndns.org
| Quote: | 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.
| Quote: |
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. |
|
| Back to top |
|
|
John L Rice
Guest
|
| Posted: Tue Jun 05, 2007 9:38 am Post subject: Re: SAS and SATA (arrays) on one controller (LSISAS1068)? |
|
|
| Quote: | 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 |
|
| Back to top |
|
|
Folkert Rienstra
Guest
|
| Posted: Wed Jun 06, 2007 12:52 am Post subject: Re: SAS and SATA (arrays) on one controller (LSISAS1068)? |
|
|
"John L Rice" <Drummer@ImJohn.com> wrote in message news:1369q5nror6643c@corp.supernews.com
| Quote: | 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.
| Quote: |
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.
| Quote: |
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.* |
|
| Back to top |
|
|
John L Rice
Guest
|
| Posted: Wed Jun 06, 2007 6:34 am Post subject: Re: SAS and SATA (arrays) on one controller (LSISAS1068)? |
|
|
"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message
news:4665f8e0$0$97270$892e7fe2@authen.yellow.readfreenews.net...
| Quote: | "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 |
|
| Back to top |
|
|
Fix your Windows Problems - FAST.
FREE Safe Scan Registry Check. Locate & Fix Errors in Minutes!
|
|
|
|
| |
Watched Topics
Search
Register
Log in to check your private messages
Profile
Log in
Memberlist
Usergroups