Drie nieuwe schijven voor opslag en servers van Hitachi
Hitachi heeft gisteren drie nieuwe harddisks aangekondigd voor opslagsystemen en servers. Naast een model met hoge opslagcapaciteit en een exemplaar voor kritische data komt het bedrijf voor het eerst met een small-form-factorschijf voor de zakelijke markt.
De Ultrastar 15K300 is gebouwd voor opslag van kritische zakelijke informatie, oftewel tier 1 opslagmedia, en is daarom voorzien van Rotational Vibration Safeguard. Deze technologie registreert vibraties en past de positie van de lees- en schrijfkop daar op aan zodat deze op de juiste plek blijft. Ook is Thermal Fly-height Control toegevoegd, die de foutgevoeligheid bij hoge temperaturen moet minimaliseren. Verder draait de 3,5"-schijf op 15.000 rpm en wordt met een opslagcapaciteit van maximaal 300GB geleverd. Naast een 3Gbit per seconde sas-interface, is de schijf voorzien van Ultra320 scsi en 4Gbit per seconde fibre channel.
De Ultrastar A7K1000 moet vooral veel opslagcapaciteit voor weinig geld leveren en wordt verscheept met een grootte van 1TB en een 3Gbps sata interface. De 2,5" sff-schijf C10K147 tenslotte is bedoeld voor servers. Dit kleintje draait op 10.000 rpm, is voorzien van een 3Gbps sas-interface en bevat maximaal 147GB. Hitachi noemt de C10K147 een 'key product' en verwijst naar een onderzoek van IDC dat stelt dat overwegingen om kosten, ruimte en energieverbruik te reduceren in datacenters tot een verschuiving naar sff-drives zullen leiden, waardoor de afzet van dit type schijf zal toenemen van 2,4 miljoen in 2006 naar 9,4 miljoen in 2007.
Reacties (37)
Hopelijk zijn de nieuw 2,5" schijven wel een stuk beter dan de schijven die IBM nu gebruikt in de bladecentre's, die lijken wel bij bosjes defect te gaan.
De 2,5" sff-schijf C10K147 tenslotte is bedoeld voor servers. Dit kleintje draait op 10.000 rpm, is voorzien van een 3Gb per seconde sas-interface en bevat maximaal 147GB
klinkt als een concurrent voor de Rptor maar dan net weer iest kleiner (2,5")... ook geschikt voor in d elaptop dus..
ben beniwued naar de eerste benchmarks... alleen snap niet dat hele verhaal :
Hitachi noemt de C10K147 een 'keyproduct' en verwijst naar een onderzoek van IDC dat stelt dat overwegingen om kosten, ruimte en energieverbruik te reduceren in datacenters tot een verschuiving naar sff zullen leiden
ruimte en energieverbruik reduceren... ruimte snap ik aangezien formfactor kleiner is (die 2,5"), verbruik weet ik niet zo, schijf is wel kleiner maar draait wel op 10k rpm... en het laatste de kosten.. deze zullen qua aanschaf wel hoger liggen, maar neem aan dat dat dan weer gecompenseerd wordt door ruimte en energieverbruik ???
ach jah, marketing is nooit iets voor mij geweest
klinkt als een concurrent voor de Rptor maar dan net weer iest kleiner (2,5")... ook geschikt voor in d elaptop dus..
ben beniwued naar de eerste benchmarks... alleen snap niet dat hele verhaal :
Hitachi noemt de C10K147 een 'keyproduct' en verwijst naar een onderzoek van IDC dat stelt dat overwegingen om kosten, ruimte en energieverbruik te reduceren in datacenters tot een verschuiving naar sff zullen leiden
ruimte en energieverbruik reduceren... ruimte snap ik aangezien formfactor kleiner is (die 2,5"), verbruik weet ik niet zo, schijf is wel kleiner maar draait wel op 10k rpm... en het laatste de kosten.. deze zullen qua aanschaf wel hoger liggen, maar neem aan dat dat dan weer gecompenseerd wordt door ruimte en energieverbruik ???
ach jah, marketing is nooit iets voor mij geweest
Heb jij ooit een laptop gezien met een SAS-interface? Ik (nog) niet, als je er eentje weet, let me know...Dit kleintje draait op 10.000 rpm, is voorzien van een 3Gb per seconde sas-interface en bevat maximaal 147GB.
SAS-interface is backwards compatible met SATA.
NEE. een SAS disk op een SATA controller doet niets. SAS gebruikt om te beginnen afaik een hoger voltage, om het over protocolprobleempjes nog maar niet te hebben.
SAScontrollers kunnen toevallig wel SATA disken aansturen maar omgekeerd gaat niet lukken.
SAScontrollers kunnen toevallig wel SATA disken aansturen maar omgekeerd gaat niet lukken.
Ik geloof dat de meeste drives van 10k+ RPM 2,5" zijn, dus dat zijn dan niet direct schrijven die voor de laptop geschikt. Denk ook niet dat dat noujuist de bedoeling is van deze schrijven.
Dat laptop schijven en deze ongeveer net zo breed zijn wil niet zeggen dat het vergelijkbare schijven zijn.
Slimline DVD is ook ongeveer net zo breed als een "normale" 5 1/4" DVD speler. Toch zou ik niet willen zeggen dat het net zo groot zijn en dus beide in de laptop passen.
[reactie op cramwinckel]
Het duurt nog wel even voordat de meeste 10k+ RPM schijven het formaat 2.5" hebben.
Bijna alle scsi schijven van dit moment zijn 3,5" en worden bijna allemaal geleverd in 10-15K RPM.
Er is wel een verschuiving naar 2,5" maar over dominantie durf ik nog niet te spreken.
Slimline DVD is ook ongeveer net zo breed als een "normale" 5 1/4" DVD speler. Toch zou ik niet willen zeggen dat het net zo groot zijn en dus beide in de laptop passen.
[reactie op cramwinckel]
Het duurt nog wel even voordat de meeste 10k+ RPM schijven het formaat 2.5" hebben.
Bijna alle scsi schijven van dit moment zijn 3,5" en worden bijna allemaal geleverd in 10-15K RPM.
Er is wel een verschuiving naar 2,5" maar over dominantie durf ik nog niet te spreken.
Wacht ff hoor ?
Die Ultrastar 15K300 heeft op 1 en dezelfde schijf 3 verschillende aansluitingen ?
Of is hij in 3 smaaken leverbaar ?
Die Ultrastar 15K300 heeft op 1 en dezelfde schijf 3 verschillende aansluitingen ?
Of is hij in 3 smaaken leverbaar ?
zo staat het er iig wel
beetje logisch nadenkenVerder draait de 3,5"-schijf op 15.000 rpm en wordt met een opslagcapaciteit van maximaal 300GB geleverd. Naast een 3Gbit per seconde sas-interface, is de schijf voorzien van Ultra320 scsi en 4Gbit per seconde fibre channel.
3 verschillende soorten schijven:
15K300 > SAS interface
15K300 > SCSI interface
15K300 > FIB interface
Een 300GB 15K schijf dat is flink en nog niet eerder gezien? Perpendeculair werpt ook bij 15K schijven zijn vruchten af. In een RAID set zal dit zeer snel zijn met flink wat opslag. Mooie ontwikkeling.
ik denk na en ik kan lezen; 
ik denk dat ze bedoelen wat jij zegt,
maar er staat dat de schijf alle drie de interfaces heeft.
jammer dat het artikel geen (werkende) link heeft naar Hitachi
ik denk dat ze bedoelen wat jij zegt,
maar er staat dat de schijf alle drie de interfaces heeft.
jammer dat het artikel geen (werkende) link heeft naar Hitachi
jaja 10.000rpm voor in de labtop
dat maakt en kabaal en slurpt stroom
Dat is toch echt bedoeld voor opslag systemen.
dat maakt en kabaal en slurpt stroom
Dat is toch echt bedoeld voor opslag systemen.
Alsof alle ventilatoren in een laptop 120mm silenced papst fans zijn?
De meeste laptops klinken nog steeds alsof er iets aan het opstijgen is met die 40mm fannetjes..zeker bij intensief gebruik
De meeste laptops klinken nog steeds alsof er iets aan het opstijgen is met die 40mm fannetjes..zeker bij intensief gebruik
In het artikel staat ook "is bedoeld voor Servers"
Lijkt me wel iets voor op bladeservers.
Lijkt me wel iets voor op bladeservers.
"Naast " impliceerd beide interfaces.
impliceert 
Is het niet handiger of goedkoper om in plaats van één zeer snelle schijf met een beperkte opslagcapaciteit, die ook nog eens heel heet wordt, twee langzamere schijven in te zetten?
Waarschijnlijk kunnen twee harde schijven van 7200 tpm samen minstens zoveel data verwerken, worden minder warm en kosten bij elkaar ook nog minder. Bovendien geven ze samen een stuk meer opslagcapaciteit.
Waarschijnlijk kunnen twee harde schijven van 7200 tpm samen minstens zoveel data verwerken, worden minder warm en kosten bij elkaar ook nog minder. Bovendien geven ze samen een stuk meer opslagcapaciteit.
In goede opslagsystemen is voldoende airflow.
2x 7200 raid 0 is 1,5 x access times is dus slecht
Kun je deze stelling onderbouwen?
Je bent namelijk de eerste die ik ken die de accesstime omhoog ziet gaan bij RAID 0....
Je bent namelijk de eerste die ik ken die de accesstime omhoog ziet gaan bij RAID 0....
access times bij raid 0 gaan omhoog in milliseconden dus is langzamer.
Je hebt zelfs geen benchmarks nodig om te begrijpen dat 2 schijven in raid 0 hogere acces times hebben dan een enkele schijf. Er moeten immers 2 schijfkoppen gepositioneerd worden voor elke read/write. En ook al zijn het twee identieke schijven, ze zullen nooit precies alle handelingen exact even snel uitvoeren waardoor je gewoon wat hogere acces times zult krijgen.
Met Raid 0 gaat de doorvoer snelheid omhoog, maar de acces times ook.
Met Raid 0 gaat de doorvoer snelheid omhoog, maar de acces times ook.
Ehm, dus als ik een enterprise storage systeem heb met 240 disken dan is de accesstijd ook 100x hoger...?
dus disk 10K is 4ms access time, 240 disken is 400ms?
In dat geval zou NIEMAND aan raid beginnen...het voordeel van RAID is juist dat je paralel data kunt accessen, en dat je service tijd LAGER wordt...
dus disk 10K is 4ms access time, 240 disken is 400ms?
In dat geval zou NIEMAND aan raid beginnen...het voordeel van RAID is juist dat je paralel data kunt accessen, en dat je service tijd LAGER wordt...
Dus jij gaat 240 disken in raid 0 hangen? 
Als je logisch nadenkt begrijp je dat de access time bij twee schijven in raid 0 hoger is als bij 1 enkele schijf. Als je dan van twee naar vier schijven gaat is het ook weer logisch dat deze access tijd niet geheel verdubbelt maar dat er slechts weer iets meer vertraging optreed. Zoals Johan C. het zou zeggen: Ieder voordeel hep z'n nadeel
Als je logisch nadenkt begrijp je dat de access time bij twee schijven in raid 0 hoger is als bij 1 enkele schijf. Als je dan van twee naar vier schijven gaat is het ook weer logisch dat deze access tijd niet geheel verdubbelt maar dat er slechts weer iets meer vertraging optreed. Zoals Johan C. het zou zeggen: Ieder voordeel hep z'n nadeel
Wat is dan in godsnaam jullie definitie van accesstijd?
Lijkt mij logisch dat als je een bestand over 4 disken verspreid, je dit bestand van 4 disken kan lezen in stukjes i.p.v van 1 disk. Aangezien het ZOEKEN van de data de meeste tijd neemt, en dit de bottleneck is voor een disk, moet het lezen van een bestand verspreid over 4 disken aanzienlijk sneller gaan..
een standaard access bestaat uit positioneren, dat is gemiddeld een rondje + een halve ronde (dus bij 4ms rotational latency is dat al 6ms), en dat het lezen van de data (size in blocks : aantal blocks per track : 4ms) dus als je 250 sectoren hebt per track a 0.5KB, en je leest een sector van 0.5KB, dan is de latency daarvoor 4ms/250) .. dus ben je daar al meer dan 6ms mee bezig.. indien een ander stuk van je file ergens anders op disk staat geld zelfde verhaal... dus 24ms + voor 4 stukjes. Indien deze 4 stukjes over 4 disken zijn verspreid kun je dit paralel zoeken.. dus effectief 6ms in totaal...
Of ik begrijp iets niet....
Lijkt mij logisch dat als je een bestand over 4 disken verspreid, je dit bestand van 4 disken kan lezen in stukjes i.p.v van 1 disk. Aangezien het ZOEKEN van de data de meeste tijd neemt, en dit de bottleneck is voor een disk, moet het lezen van een bestand verspreid over 4 disken aanzienlijk sneller gaan..
een standaard access bestaat uit positioneren, dat is gemiddeld een rondje + een halve ronde (dus bij 4ms rotational latency is dat al 6ms), en dat het lezen van de data (size in blocks : aantal blocks per track : 4ms) dus als je 250 sectoren hebt per track a 0.5KB, en je leest een sector van 0.5KB, dan is de latency daarvoor 4ms/250) .. dus ben je daar al meer dan 6ms mee bezig.. indien een ander stuk van je file ergens anders op disk staat geld zelfde verhaal... dus 24ms + voor 4 stukjes. Indien deze 4 stukjes over 4 disken zijn verspreid kun je dit paralel zoeken.. dus effectief 6ms in totaal...
Of ik begrijp iets niet....
quote :
Dus jij gaat 240 disken in raid 0 hangen?
Als je logisch nadenkt begrijp je dat de access time bij twee schijven in raid 0 hoger is als bij 1 enkele schijf. Als je dan van twee naar vier schijven gaat is het ook weer logisch dat deze access tijd niet geheel verdubbelt maar dat er slechts weer iets meer vertraging optreed. Zoals Johan C. het zou zeggen: Ieder voordeel hep z'n nadeel
/quote
Uiteraard niet, maar als je het hebt over het LEZEN van data maakt het ook eigenlijk niet uit welk RAID level je hebt....
Dus jij gaat 240 disken in raid 0 hangen?
Als je logisch nadenkt begrijp je dat de access time bij twee schijven in raid 0 hoger is als bij 1 enkele schijf. Als je dan van twee naar vier schijven gaat is het ook weer logisch dat deze access tijd niet geheel verdubbelt maar dat er slechts weer iets meer vertraging optreed. Zoals Johan C. het zou zeggen: Ieder voordeel hep z'n nadeel
/quote
Uiteraard niet, maar als je het hebt over het LEZEN van data maakt het ook eigenlijk niet uit welk RAID level je hebt....
R0 2 schijven 5.6ms
R0 4 schijven 5.6ms
R0 8 schijven 5.7ms
R1 2 schijven 4.7ms
R10 4 schijven 4.8ms
R10 6 schijven 4.8ms
R10 8 schijven 4.8ms
R5 4 schijven 5.7ms
R50 6 schijven 5.6ms
R50 8 schijven 5.6ms
(LSI 320-2E / S.C. 15K.4 36GB's / HDtach 3.0.1.0 / R.A.)
[edit]
Deze benchmarks zijn alleen ter vergelijking onderling betreft kwantiteit en Raidlevels. Meten = weten. Het gaat niet om de kwaliteit. Met Sisoft zit ik op 3ms, maar is niet aan de orde daar HDtach met 2 significante cijfers werkt, en onderling de testen gelijk zijn.
R0 4 schijven 5.6ms
R0 8 schijven 5.7ms
R1 2 schijven 4.7ms
R10 4 schijven 4.8ms
R10 6 schijven 4.8ms
R10 8 schijven 4.8ms
R5 4 schijven 5.7ms
R50 6 schijven 5.6ms
R50 8 schijven 5.6ms
(LSI 320-2E / S.C. 15K.4 36GB's / HDtach 3.0.1.0 / R.A.)
[edit]
Deze benchmarks zijn alleen ter vergelijking onderling betreft kwantiteit en Raidlevels. Meten = weten. Het gaat niet om de kwaliteit. Met Sisoft zit ik op 3ms, maar is niet aan de orde daar HDtach met 2 significante cijfers werkt, en onderling de testen gelijk zijn.
R5 8 disken U160 10k rpm SCSI. ik zie tussen 8 disk R5 en 1disk R0 (los schijfje dus) een paar tiende ms verschil.
maar, ik snap wel waar het vandaan komt. onze diskjes [/snob] hebben iets genaamd spindle sync oid, die hebben hun schijfjes zo zitten dat er hiervoor geoptimaliseerd wordt afaik. een 7200rpm desktopdingetje heeft zoiets niet dus als je die in R0 zet zouden (let wel, ik heb het nooit geprobeerd) een grotere vertraging kunnen geven.
toch heb je met zulke vertragingen wel een ontzettend brak setje disken. verdubbeling, ouch, moet er niet aan denken
maar, ik snap wel waar het vandaan komt. onze diskjes [/snob]
hebben iets genaamd spindle sync oid, die hebben hun schijfjes zo zitten dat er hiervoor geoptimaliseerd wordt afaik. een 7200rpm desktopdingetje heeft zoiets niet dus als je die in R0 zet zouden (let wel, ik heb het nooit geprobeerd) een grotere vertraging kunnen geven.toch heb je met zulke vertragingen wel een ontzettend brak setje disken. verdubbeling, ouch, moet er niet aan denken
@scsi-freak
Je vergeet dat hoewel 4 schijven evenveel werk moeten verzetten, ze dit nooit allemaal 100% synchroon zullen doen. En het vervelende is dat de 3 'snelste' schijven allemaal moeten wachten totdat de laatste klaar is voordat ze aan de volgende opdracht kunnen beginnen. Daarom is de latency van een raid array altijd hoger dan die van een enkele schijf. En hoe meer schijven je hebt, hoe groter de kans dat schijven op elkaar moeten wachten.
Je vergeet dat hoewel 4 schijven evenveel werk moeten verzetten, ze dit nooit allemaal 100% synchroon zullen doen. En het vervelende is dat de 3 'snelste' schijven allemaal moeten wachten totdat de laatste klaar is voordat ze aan de volgende opdracht kunnen beginnen. Daarom is de latency van een raid array altijd hoger dan die van een enkele schijf. En hoe meer schijven je hebt, hoe groter de kans dat schijven op elkaar moeten wachten.
BS. Als twee schepen naar Amerika varen duurt het ook niet twee keer zo lang.
De logic op de SAS controller stuurt over de bus een signaal naar de logic van de schijf en deze verwerken nagenoeg gelijk de opdracht. Het zou toch wel vreemd wezen dat er in servers zoveel raid 1, 5 en 10 voorkomt als er zo'n groot nadeel aan zou zitten.
De logic op de SAS controller stuurt over de bus een signaal naar de logic van de schijf en deze verwerken nagenoeg gelijk de opdracht. Het zou toch wel vreemd wezen dat er in servers zoveel raid 1, 5 en 10 voorkomt als er zo'n groot nadeel aan zou zitten.
Inderdaad. Tenzij er tussen schepen en rederij één loopjongen heen en weer moet rennen en de rederij niet aan de kade zit maar zeg in Berlijn. Dat is het geval bij PATA (IDE) master en slave op dezelfde kabel en bij domme/softwarematige RAID controllers. Ik denk dat veel mensen daar nog het idee vandaan halen dat RAID persé een hogere latency moet hebben.BS. Als twee schepen naar Amerika varen duurt het ook niet twee keer zo lang.
Voor SATA en SAS met een beetje goede controller zou er nauwelijks verschil moeten zijn, op enkele uitzonderingen na: tijdelijk bij temperatuurgerelateerde hercalibraties van een van de schijven, of permanent door fragmentatie door bad sectoren, hoewel een echt intelligente controller dan de goede schijf ook dat gebied zou laten verschuiven waardoor stripes altijd fysiek op identieke plekken terechtkomen.
Edit: Volgens mij gaat dit draadje over schijven, en mijn bericht over schijftechnologie, in een rij met een dozijn andere berichten met het zelfde subonderwerp, dus waar komt dat Score: 0 (Off-topic) vandaan?
klopt, niet twee keer zo lang, maar het duurt wel héél iets langer voor ze *beide* aan de andere kant zijn bij zelfde vertrektijd (~zwakste schakel), al is het maar een paar seconden... of microseconden in het geval van raid0, veroorzaakt door willekeurige dataposities. De toeren omhoog halen werkt natuurlijk wel prima, net als op de boot (;twee schepen amerika duurt niet twee keer zo lang
Jij haalt nu twee dingen door elkaar.
Latencie en sustrained.
Het voorbeeld wat jij aanhaalt is de doorvoer snelheid.
Die is in optimale omstandigheden idd dubbel zo hoog als bij een enkele schijf.
Latencie wil echter zeggen hoe lang het duurt voor de juiste bit gevonden is.
Je kunt je toch voorstellen dat het langer duurt om 2 schijfkoppen in positie te brengen dan om maar 1 te positioneren.
Latencie en sustrained.
Het voorbeeld wat jij aanhaalt is de doorvoer snelheid.
Die is in optimale omstandigheden idd dubbel zo hoog als bij een enkele schijf.
Latencie wil echter zeggen hoe lang het duurt voor de juiste bit gevonden is.
Je kunt je toch voorstellen dat het langer duurt om 2 schijfkoppen in positie te brengen dan om maar 1 te positioneren.
Nee, niet echt. Net als met die schepen: het gaat nooit langer duren dan het langzaamste schip er in zijn eentje over doet.
Dat schip gaat niet langzamer varen omdat er een sneller schip meevaart.
Als het 3 minuten kost om 1 ei te koken, kost het zes minuten om er twee te koken?
Dat schip gaat niet langzamer varen omdat er een sneller schip meevaart.
Als het 3 minuten kost om 1 ei te koken, kost het zes minuten om er twee te koken?
Argh! Waar blijft de concurrentie op 10.000rpm SATA gebied?
Jammer, hier kijk ik nog altijd naar uit.
Jammer, hier kijk ik nog altijd naar uit.
Ik las op de site van Hitachi dat de Ultrastar A7K1000 geleverd wordt met een capaciteit van 500, 750 of 1000 GB en hij gaat gewoon de standaard 7200 toeren per minuut draaien. de opgegeven seek time: 8,2 ms, de databuffer is bij alle modellen 32 MB.
Hitachi
Hitachi
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games Politiek en recht Consoles
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
