Gå til innhold

Sata og ide i raid0?


Anbefalte innlegg

Videoannonse
Annonse
Jeg skal kjøpe harddisk og jeg lurer på om det går ann å kjøre en sata harddisk og en IDE harddisk i raid0??

6006882[/snapback]

Enten på operativsystemet ditt støtte dette, eller så må du ha en kontroller som støtter raid fra både ide og sata. Kontrolleren på hovedkortet mitt gjør for eksempel dette. Hvis du oppgir hva slags kontroller (evt hovedkort hvis kontrolleren sitter på dette) og operativsystem du har, så kanskje noen kan hjelpe deg.

 

Og for all del, raid er ikke forbeholdt sata, det var å finne på såvel scsi, fibrechannel og ide før sata kom til verden. raid0 er forøvrig strengt tatt ikke raid, i og med at det ikke er noen redundans, men det blir flisespikkeri :)

Lenke til kommentar
RAID er vel bare for SATA disker...

6006979[/snapback]

 

Overhodet ikke. RAID er en teknologi som har eksistert en god stund. Finnes masse raidløsninger både for scsi, ide og sata.

 

Skjønt å kombinere sata og ide i samme array vet jeg ikke om er mulig. Om det ikke finnes hardwareløsninger på det, kanskje man kan lure til noe med software?

 

EDIT:

Jeg endrer svaret mitt til, JA, det går an :)

Du får det mest sannsynlig til å software, men det finnes også hardware som støtter mixed pata/sata RAID. (F.eks ABIT Fatal1ty AN8) Sjekk manualen til hovedkortet ditt, eventuelt RAID kontrolleren om du har støtte for mixed media RAID.

Endret av Kjellvez
Lenke til kommentar
RAID er vel bare for SATA disker...

6006979[/snapback]

Det er kansje en idé å sette seg inn ting før man kommer med sånne utsagn. Rettlære er mye vanskeligere når man først har blitt vranglært.

 

Det skal vel teoretisk være mulig hvis du kjører dem i software raid

6006992[/snapback]

Ikke bare teoretisk, men også praktisk fullt mulig.

 

I praksis er det ikke noe i veien for å kjøre de i hardware-raid heller. Det finnes vanlige kontrollere som har 2xSATA + 1x PATA som støtter Raid0, og det finnes overganger mellom SATA og PATA som kan brukes for å kjøre disker med ulikt grensesnitt på en kontroller som bare støtter ett av grensesnittene.

 

SATA-150 og den ikke-eksisterende standarden "SATAII" er kompatible med hverandre og du kan fint kjøre en SATA-150 disk på en kontroller som støtter SATA-300 eller omvendt.

Lenke til kommentar

S-ATA 2 disker på S-ata 150 kontrollere funker fint. Har gjort det to ganger nå. Er du litt uheldig må du benytte en jumper for å få det til å funke. Og ytelsen du mister er nok mest teoretis

 

IDE

Two IDE connectors that allows connecting up to four UltraDMA 133Mbps hard drives

 

NVIDIA RAID allows RAID arrays spanning across Serial ATA and Parallel ATA

 

RAID 0, RAID 1 and RAID 0+1

  Serial ATA with RAID

 

Dette (hentet fra Dfi sida komplett linker til) betyr vel at kortet støtter hardware Raid på S-ATA og Pata?

Lenke til kommentar
. . . det finnes overganger mellom SATA og PATA som kan brukes for å kjøre disker med ulikt grensesnitt på en kontroller som bare støtter ett av grensesnittene.

6010210[/snapback]

Er ikke sikker nå, men jeg kan se for meg et problem hvis den overgangen utgjør en liten forsinkelse i forhold til en harddsik som er koblet direkte uten overgang hvis man prøver å sette disse opp i raid0 eller raid5.

 

Man kansje enkelte kontrollere/software faktisk har mekanismer som kan oppdage at den ene disken leverer dataene sine litt senere enn den andre. Noen som vet?

 

Skal uansett ikke være problematisk for jbod eller raid1 :cool:

Endret av geir__hk
Lenke til kommentar

geir__hk: Det er sikkert logisk å tenke at en overgang kan gi en forsinkelse, men nå har jo elektroniske og mekaniske systemer svært ulik hastighet i utgangangspunktet. Dvs. Elektriske systemer (som en overgang) vil kunne behandle og overføre data på mikrosekunder (10^-6 sekunder) om ikke mindre enn det også, mens f.eks den mekaniske søketida er på flerfoldige millisekunder (ofte gjennomsnittlig rundt 8ms) og i tillegg kommer rotasjonsforsinkelsen på i gjennomsnitt 4,17ms på 7200rpm-disker. Aksesstiden vil altså være i størrelseorden 1000 ganger større (og svært variabel) enn elektroniske forsinkelser i en overgang. Så den forsinkelsen overgangen utgjør er altså en dråpe i havet i forhold til forskjeller i forsinkelsene i selve disken.

 

PATA og SATA-disker er ikke mulig å kjøre i Raid med synkroniserte spindler. Diskene har også adskillt fysisk og virituell adressering samt reservesektorer som gjør at aksesstiden alltid vil være forskjellig på diskene som står i raid. F.eks kan den ene disken levere sine data etter f.eks 2ms, mens den andre bruker 15ms på å levere sine. Overgangens forsinkelse på i størrelseorden 0,001 ms er altså en dråpe i havet i forhold til variasjonene i aksesstider som ofte er flerfoldige ms.

Lenke til kommentar
PATA og SATA-disker er ikke mulig å kjøre i Raid med synkroniserte spindler. Diskene har også adskillt fysisk og virituell adressering samt reservesektorer som gjør at aksesstiden alltid vil være forskjellig på diskene som står i raid. F.eks kan den ene disken levere sine data etter f.eks 2ms, mens den andre bruker 15ms på å levere sine. Overgangens forsinkelse på i størrelseorden 0,001 ms er altså en dråpe i havet i forhold til variasjonene i aksesstider som ofte er flerfoldige ms.

6010582[/snapback]

Kan du begrunne dette, eller komme med dokumentasjon? Hovedkortet mitt støter RAID med en kombinasjon av PATA og SATA. Flere leverandører leverer også eksakt de samme diskene, med identiske spesifikasjoner bortsett fra grensesnitt. Et lite utvalg:

 

Seagate:

Maxtor:

Hitachi:

Jeg tror det du egentlig mener å si er at man ikke bør blande disker med forksjellige spesifikasjoner i raid, mens det egentlig er mer eller mindre ett fett hvilket grensesnitt de forskjellige diskene har.

Endret av roac
Lenke til kommentar

Begrunnelse:

 

2 like harddisker snurrer med f.eks 7200rpm. Begge har sine egne kretser som holder hastigheten nogenlunde konstant. Det er ikke dermed sagt at hastigheten ikke har noe som helst usikkerhet. La oss si den ene disken snurrer med 7199 rpm og den andre med 7201 rpm. På et gitt tidspunkt ønsker man at begge diskene skal lese synkront fra en bestemt fil. La oss si at lesehodene står på riktig sylinder så det slipper å bevege seg. På den ene harddisken er platene snurret til det punktet at lesehodet kan begynne å lese med en gang. Aksesstid: ca 0ms. På den andre disken kan platene ha snurret sånn at disken må ta nesten en hel omdreining før lesehodet kan begynne å lese. En hel omdreining ved 7200rpm tar 8,33 ms. Den andre disken vil altså begynne å lese 8,33 ms etter den andre.

 

Ok, nå har jeg begrunnet det med rotational latency. Så over til søketid:

Søketiden er den tiden det tar fra disken får komandoen les til lesehodet står på riktig sylinder klar til å lese. Aksesstid = søketid + rotational latency.

 

Aksesstiden som oftest oppgis på disker er gjennomsnittlig søketid. Dvs. søketiden kan variere. Også på identiske disker. En disk har fysisk og virituell adressering for at disken selv skal kunne beskytte OS'et og brukeren mot feil. Hvis et område på disken blir ødelagt eller overskrevet så mange ganger at det sklir litt ut av posisjon (noe som er relativt vanlig) så kan elektrinikken i disken lese innholdet på det problematiske området før det blir uleselig, flytte det til en av reservesektorene og markere det problematiske området som skadet. OS'et vil ikke merke noe til dette siden det forholder seg til den virituelle adresseringen av disken. Hvis Raid-kontrolleren ønsker å lese fra et bestemt (virituellt) adresseområde så kan det hende at den ene disken leser sektoren fra der den burde ligge, mens den andre disken kan måtte lese fra reservesektorene. Dette gjør at lesehodene på de to diskene må flytte seg forskjellig avstand og dermed bruke forskjellig tid. Forskjellen kan i teorien komme opp i rundt 15-18 ms på vanlige 7200rpm-disker.

 

Legg det sammen med rotational latency på opp til 8,33ms så kan diskene komme med dataene så forskjellig som over 20ms.

 

En disk som leser med 50MB/s vil på 20ms kunnet lese 1MB. Den ene disken kan dermed i teorien ligge så mye som 1MB før den andre.

 

At elektronikk (en overgang) har ekstremt mye raskere respons enn et mekanisk system er ikke vanskelig å se for seg og sansynliggjøre.

 

Var det begrunnelse nok?

Lenke til kommentar
Jeg tror det du egentlig mener å si er at man ikke bør blande disker med forksjellige spesifikasjoner i raid, mens det egentlig er mer eller mindre ett fett hvilket grensesnitt de forskjellige diskene har.

6012227[/snapback]

Ja, det kan du godt si. (Men det er normalt ikke så mye å tape på at diskene har forskjellige spesifikasjoner heller)

Lenke til kommentar

FYI: Det er ingenting som heter SATA1 og SATA2 :)

 

Programvare-RAID har den fordelen at informasjonen om RAIDsettene lagres i MBR (starten) delen på en disk, og dermed kan diskene strengt tatt være hva som helst, så lenge operativsystemet klarer å lese de. Du kan til og med dra de ut, for så å koble de til igjen hvordan du selv vil. For programmet som styrerer RAID-settet vil selv kunne vite hvilken disk som hører til hvor i et RAID sett :)

Lenke til kommentar

Lurer på en ting til: Simen1 forteller mye om forsinkelse på harddiskene og ørliten forskjell i rotasjonshastighet. Jeg lurer: Har ikke raid-kontrolleren mulighet til å overstyre hardiskens rotasjon, sånn at diskene faktisk snurrer synkront.

 

En annen ting: Hvis harddiskene leser relativt store blokker hver, ikke at dem veksler på byte-niva men kanskje på 512 byte eller noe sånt. Da vil vel ikke mangel på nøyaktig synkronisering utgjøre så stor forskjell?

 

Og søkehastigheten vil som jeg forstod det ligge en plass mellom tilnermet 0 ms og maximum søketid for hver disk x2. Altså gjennomsnittlig søketid dobles.

Endret av geir__hk
Lenke til kommentar
Lurer på en ting til: Simen1 forteller mye om forsinkelse på harddiskene og ørliten forskjell i rotasjonshastighet. Jeg lurer: Har ikke raid-kontrolleren mulighet til å overstyre hardiskens rotasjon, sånn at diskene faktisk snurrer synkront.

Noen dyre SCSI RAID-kontrollere har vist denne muligheten. De klarer likevel ikke å synkronisere de fullstending, men er ganske nært. Så vidt jeg vet er det bare et fåtall SCSI-disker som støtter synkronisering, så det er langt i fra dagligdags. Vanlige kontrollere og vanlige harddisken har ikke denne muligheten. Men la oss si at vi får to disker til å snurre med mye likere hastighet, f.eks 7200,0 rpm og 7200,1 rpm. Hvis diskene snurrer helt synkront et gitt øyeblikk, så vil det ta 5 minutter før den ene disken har snurret en halv omdreining mer enn den andre. 5 minutter senere har den ene tatt en omdreining mer enn den andre og de er synkrone igjen. Slike fortsetter det å veksle hvert 5. minutt. Merk, dette er når diskene går med veldig liten forskjell i hastighet.

 

En annen ting: Hvis harddiskene leser relativt store blokker hver, ikke at dem veksler på byte-niva men kanskje på 512 byte eller noe sånt. Da vil vel ikke mangel på nøyaktig synkronisering utgjøre så stor forskjell?

Differansen kan som nevnt i posten over være på over 20ms. Dette tilsvarer rundt 1MB på en moderne disk. Den ene disken kan altså ende opp å lese 1MB før den andre får plassert lesehodet og begynnt å lese. Å ha blokker så store som f.eks 64kB er ikke i nærheten av nok for at manglende synkronisering skal bagatelliseres. Vanlig blokkstørrelse er forresten 4-64kB.

 

Og søkehastigheten vil som jeg forstod det ligge en plass mellom tilnermet 0 ms og maximum søketid for hver disk x2. Altså gjennomsnittlig søketid dobles.

6017674[/snapback]

Det stemmer. Den søketiden (tiden det tar å flytte lesehodet til riktig plass på disken) er den gjennomsnittlige. Maksimalt ("full stroke seek") er den ca dobbelt så høy som gjennomsnittlig. Da flytter lesehodet seg fra helt inners på disken til ytterst eller omvendt. Altså rundt 17ms søketid og dermed totalt over 20ms aksesstid.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...