Seagate lanserar snabb 2,5-tumshårddisk

Permalänk
Melding Plague

Seagate lanserar snabb 2,5-tumshårddisk

Seagate lanserade igår världens första 2,5-tumshårddisk som har en rotationshastighet på 15 000 varv per minut (rpm). Hårddisken finns tillgänglig med en lagringskapacitet på 36 eller 73 gigabyte med en 16 megabytes buffer.

Läs nyheten: Seagate lanserar snabb 2,5-tumshårddisk

Visa signatur

Observera att samma trivselregler gäller i kommentarstrådarna som i övriga forumet och att brott mot dessa kan leda till avstängning. Kontakta redaktionen om du vill uppmärksamma fel i artikeln eller framföra andra synpunkter.

Permalänk
Medlem

ge mig till satagränssinttet så blir jag nöjd.

Visa signatur

P182 | Asus Z170-A | i7 6700k | R9 290X | 2x8GB Corsair 2400MHz Cl14 | Intel 750 400MB | TBs of diskstorage

Permalänk
Medlem

Riktigt grymt! De diskarna verkar vara framtiden för servrar...

Men det hade varit koolt med sata på dessa diskar
Riktigt snabba laptops man kunnat få då

Visa signatur

Kan starkt rekommendera Honeygain. Dela din internetuppkoppling och få betalt. Används inte för något konstigt utan saker som SEO, Ad verification och App testing.
Använd gärna min länk så får du $5 att starta med :)
https://r.honeygain.me/PONTU9D128

Permalänk
Medlem

Och varma...

Visa signatur

Stolt användare av en ibook 300 MHz (dasslocket)

Permalänk
Medlem

ja det är ju främst hårddiskar som håller tillbaka laptopsarna. släng in dem i laptops.

Visa signatur

HD5770 1GB| Phenom 2 x2 555 3.2ghz BE@ x3 3.6Ghz| 2x2048ddr3 corsair xms3 1600mhz | Corsair HX520w | HP w2207| Antec 180b

Permalänk

SAS går iofs att köra på SATA, men visst, hellre tar man nog en eventuellt billigare SATA-version.

Anyway... Vill ha!

Visa signatur

That's just my opinion, I could be wrong...
> C2Q Q6700 > 8GB PC6400 > Gigabyte 965P-DQ6 > HD4870X2 & HD4650
> Lian Li PC-201B > Corsair HX620 > 10.46TB > HP LP3065 & 2x HP LP2065

Permalänk
Avstängd

borde de inte låta en hel del ?

Visa signatur

q6600 2gig ram 8800gt osv

Permalänk
Medlem

Äntligen ordentliga hdds till laptops. Kanske Dell och Apple kan byta ut de nuvarande.

Permalänk
Medlem

Nej SAS-disk går inte köra på SATA. De är inte ens kontaktmässigt kompatibla. Däremot går det köra SATA på SAS HBA. DÅ SATA-diskens kontakt passar på SAS-kablar. Men sen gäller det att den SAS-HBA man köper klarar att tunnla SATA-protokollet in till SAS-ASIC.

Men en SAS-kontroller är inte dyr idag. 2 x 36 15k Savvio i raid0 lär ju gå som tåget ,)

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av xAyiDe
Men en SAS-kontroller är inte dyr idag. 2 x 36 15k Savvio i raid0 lär ju gå som tåget ,)

Raid-0? Jag tror du skrev fel. Med Raid-0 tappar man ju accesstiden och därigenom de höga I/O-värdena.

Visa signatur

Gammal och gnällig

Permalänk
Medlem

Inte tappar man väl accesstiden? Man har ju samma accesstid på båda diskarna och därför hittar du ett varsitt fragment av filen på vardera disk, vilket borde dubbla (teoretiskt) effektiviteten?

Visa signatur

Datorer är som tonåringar, de krånglar hela tiden.

Permalänk
Medlem

Med SCSI tappar man knappt ingen prestanda på Raid0. I SATA/IDE-fallet tappar man en del. Jag menade raid0. Med en bra HBA så får man ett rejält lyft i sustained transfer och tappar inget i söktid.

Permalänk
Medlem

Ifall ni medlemmar skall aproximera kostnaden på produkten när den kommer ut? Vad skulle det ligga på då ungefär?

Kan någon dessutom länka till ett SAS-kontrollerkort? Jag tycks inte finna något.

Tack på förhand!

Visa signatur

Datorer är som tonåringar, de krånglar hela tiden.

Permalänk
Citat:

Ursprungligen inskrivet av Sneak
Inte tappar man väl accesstiden? Man har ju samma accesstid på båda diskarna och därför hittar du ett varsitt fragment av filen på vardera disk, vilket borde dubbla (teoretiskt) effektiviteten?

Överföringshastigheten ökar, men söktiden blir sämre eftersom två diskar måste bli klara med sin sökning istället för bara en som det är i vanliga fall innan operationen i fråga kan utföras.

Visa signatur

"to conquer others is to have power, to conquer yourself is to know the way"

Permalänk
Medlem

Det är ju därför du har en raidkontroller som för det första sorterar skrviningarna och cachar dem som gör att du slipper vänta på sökningarna. Du skriver till ena medans andra söker osv. Vid läsning har du read ahead vilket även detta hjälper att minimera problemet. Skulle du vänta på sökningarna hade du ju inte fått nån ökninga av sustained transfer eller hur?

Permalänk

Synd att disken är tjockare än vanliga laptop diskar annars skulle en SATA version varit en trevlig uppgradering

Visa signatur

Core2duo 5500 - 2gig - 160 gig - radeon x1400

Permalänk
Medlem

Ja annars kunde man byggt en sån här:

http://www.dailytech.com/article.aspx?newsid=2765

Fast med 15k-diskar ,)

Permalänk
Citat:

Ursprungligen inskrivet av xAyiDe
Nej SAS-disk går inte köra på SATA. De är inte ens kontaktmässigt kompatibla. Däremot går det köra SATA på SAS HBA. DÅ SATA-diskens kontakt passar på SAS-kablar. Men sen gäller det att den SAS-HBA man köper klarar att tunnla SATA-protokollet in till SAS-ASIC.

Men en SAS-kontroller är inte dyr idag. 2 x 36 15k Savvio i raid0 lär ju gå som tåget ,)

Doh, naturligtvis. Halkade visst när jag accessade mitt minne.

Visa signatur

That's just my opinion, I could be wrong...
> C2Q Q6700 > 8GB PC6400 > Gigabyte 965P-DQ6 > HD4870X2 & HD4650
> Lian Li PC-201B > Corsair HX620 > 10.46TB > HP LP3065 & 2x HP LP2065

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av xAyiDe
Det är ju därför du har en raidkontroller som för det första sorterar skrviningarna och cachar dem som gör att du slipper vänta på sökningarna. Du skriver till ena medans andra söker osv. Vid läsning har du read ahead vilket även detta hjälper att minimera problemet. Skulle du vänta på sökningarna hade du ju inte fått nån ökninga av sustained transfer eller hur?

Du har missuppfattat vad Raid-0 är.

Du skriver "Du skriver till ena medans andra söker osv."

Det är nån annan raid du tänker på.

I raid-0 på två diskar delar man upp blocken i två delar och lagrar halva blocket på ena disken och halva blocket på andra disken. För att kunna returnera första blocket i filen måste du alltså läsa halva första blocket från första disken och andra halvan från andra disken. Sen kan du pussla ihop blocket och returnera uppåt.

Nyckeln är att båda diskarna måste hitta sin halva och läsa den innan den kan pusslas ihop och lämnas tillbaka till användaren. Det går inte fortare än långsammaste disken.

Anledningen till att du får ökad sustained transfer rate är helt enkelt att två diskar skyfflar data istället för en.

Om det fortfarande inte är glasklart kan jag förklara närmare.

Visa signatur

Gammal och gnällig

Permalänk
Avstängd

När den varvar upp i en laptop så lär ju folk rapportera UFOs... tar med hela datorn

Visa signatur

ATI TALIBAN.
Är inte någon expert, men jag har inte akne heller.
NEVER UNDERESTIMATE THE POWER OF STUPID PEOPLE IN LARGE GROUPS.. "Betala i förskott på blocket?" tråden.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av Nyhet
Att använda 2,5-tumshårddiskar i serversystem är relativt nytt men är på uppgång på grund av den högre tillförlitligheten, lägre kostnaden samt mindre strömförbrukning som 2,5-tumshårddiskar har.

Varför har 2,5tumshårddiskar högre tillförlitlighet?
Och lägre kostnader? Som i billigare? Jag trodde att de var dyrare.

Visa signatur

Shuttle SN95G5v2 | Opteron 175 | G.SKILL 2GBZX 2-3-2-5 | Geforce 7800GS | Raptor 74Gb | SpinPoint F1 1TB | X-Fi Xtrem Gamer | Sennheiser HD-555 | ViewSonic VP191b

Min vattenkylda Shuttle

Permalänk
Medlem

Du har ju stripesize och den har inget med filblockens storlek att göra. Du kan ha stripesize på 64Kb och filsystemets clustersize på 4kb. DÅ kan du läsa en hel hög med block på ena disken och lämnga tillbaks till användaren medan du läser in resten på nästa disk. OM nu skulle stå och vänta på diskarna hela tiden skulle du inte öka transfer alls för då blir det ju om om du läste från en disk eller hur?
Du läser ju från båda samtidigt Men ändå inte för du läser på ena medans den andra hittar nästa data med read ahead.

Söktiden är konstant medans läshastigheten är direkt proportionell mot hur många diskar du har.

Permalänk
Medlem

Istället för att bara argumentera om hur vida accesstiden försämras, varför inte referera till lite tester?

Som det här tex av renommerade anandtech:
http://www.anandtech.com/showdoc.aspx?i=1491&p=25
"Average I/O Response" borde vara accesstidsrelaterat, inte sant?

Testet är förvisso lite gammalt men borde vara gällande även idag tycker jag.

Visa signatur

"Memory is like an orgasm. It's a lot better if you don't have to fake it." - Seymore Cray

Permalänk
Medlem

Jag skulle gärna se fler 7200 och 10 000rpm sata 2,5" diskar, som dessutom behåller sin tysthet. Jag kör med 2,5" sata-disk i min stationära och jag ÄLSKAR det, det blev underbart mycket tystare

Visa signatur

Silvertejp, silvertejp!

Permalänk
Citat:

Ursprungligen inskrivet av bomber3
När den varvar upp i en laptop så lär ju folk rapportera UFOs... tar med hela datorn

haha! Chiewiwi

Visa signatur

AMD X2 4000+, 4096 MB Corsair Value, Leadtek 8800GT 512MB, GIGABYTE GA-MA770 DS3, ANTEC P180

Permalänk
Medlem

låter billigt ^ ^

Visa signatur

,( ,( ,( ,( ,( ,( ,( ,(
`-' `-' `-' `-' `-' `-' `-' `-'

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av xAyiDe
Du har ju stripesize och den har inget med filblockens storlek att göra. Du kan ha stripesize på 64Kb och filsystemets clustersize på 4kb. DÅ kan du läsa en hel hög med block på ena disken och lämnga tillbaks till användaren medan du läser in resten på nästa disk. OM nu skulle stå och vänta på diskarna hela tiden skulle du inte öka transfer alls för då blir det ju om om du läste från en disk eller hur?
Du läser ju från båda samtidigt Men ändå inte för du läser på ena medans den andra hittar nästa data med read ahead.

Söktiden är konstant medans läshastigheten är direkt proportionell mot hur många diskar du har.

Märk ord om du vill. Jag ville inte börja prata om stripesize då det kunde vara ett okänt ord, och använde 'block' som 'del'... men vi kan göra det litet mer invecklat om du vill...

För enkelhets skull antar vi att vi har två diskar i raid-0

Vi kör med en stripe size på 64KB och försöker läsa en fil på 128K. Det betyder att filen ligger på 2st 64K-stripes, där halva stripen ligger på varje disk. Dvs. för att läsa en stripe måste varje disk läsa 32KB.

Accesstiden för en ensam disk beror på två saker, dels hur lång tid det tar för läsarmen att röra sig till rätt spår, dels hur lång tid det tar för rätt sektor (position i spåret) av disken att snurra in under läshuvudet. Om rätt sektor precis snurrat förbi, måste man vänta ett helt varv tills den kommer igen. I 15000 rpm betyder det att diskarna snurrar ett varv på 4 millisekunder. Läsarmen på en 3.5" raptor tar c:a 5.5ms i snitt för att hamna rätt. Armen på en 2.5"-disk måste röra sig kortare än på en 3.5"-disk, så vi antar att det tar i snitt 2.5/3.5 = 70% så lång tid, eller c:a 4ms. Vi får då en accesstid i snitt 2ms + 4ms = 6ms (halvt varv + läsarm i snitt) för seagates 15000rpm:are.. Vet inte om det stämmer med verkligheten då jag inte hittade några speccar på deras sida, men det låter rimligt.

Eftersom överföringshastigheten på en ensam disk är i storleksordningen 70MB/sekund (i starten, inte sustained) innebär det att den 64k-chunk av filen som varje disk har på sig teoretiskt skulle ta 64KB/70MBps ~= 0,9ms att läsa *totalt*. Notera att det är avsevärt kortare än snittaccesstiden.

1) Vi skickar ett kommando till arrayen om att vi vill läsa filen
2) Disk 1 hittar första delen av första stripen
3) Disk 1 returnerar första delen av första stripen (32KB)
4) Vi väntar på att andra disken hittar sin första stripe
5) Disk 2 hittar första delen av första stripen
6) Disk 2 returnerar första delen av första stripen (32KB)
7) Arrayen sammanfogar 32k-bitarna till en sammanhängande 64KB-stripe och returnerar den uppåt
8) Nu är båda diskarna på spåret och skyfflar data för fullt, så nu drar man äntligen nytta av raid-0. Tyvärr är det bara en stripe kvar att läsa och sammanfoga (0.45ms, då båda diskarna nu är 'på spåret'), så den vinsten äts upp av skillnaden i accesstid mellan de diskarna.

En raidkontroller kan avhjälpa en del av problemen, men den kan inte upphäva fysikens lagar.

Det enda fallet då diskarna kan läsa oberoende av varandra är ifall stripe sizen är mer än dubbelt så stor som filen du försöker läsa (där X = antalet diskar). Då kommer allt data komma från den första disken. Om detta är vanligt förekommande har du typiskt konfigurerat arrayen fel eftersom mindre än hälften av diskutrymmet utnyttjas.

Här är exempel på en kille som kör 4 raptor i Raid-0 och får den effekt jag talar om
http://www.planetamd64.com/lofiversion/index.php/t28316.html

18 ms i accesstid på 4 raptor i Raid-0 mot 8ms på singeldrive-systemet. Ganska talande tycker jag.

EDIT: Såg att jag skrivit fel på lästiden för 32k, lade till ett 'än' /EDIT

Visa signatur

Gammal och gnällig

Permalänk
Medlem

Precis, men då är vi ju tebax där vi började. Altså får man ökad transfer med bibehållen söktid?

Du pratar kanske om IDE/SATA utan NCQ eller?

Altså en scsi-kontroller använder sortering på alla sina kommandon och read ahead kommer hjälpa dig så till vida att när du vill ha hela filen 128KB kommer den att läsa in de bitar som behövs från de olika diskarna samtidigt. Då får ingen större förlust här. Men att den väntar på nästa blocket stämmer på IDE och SATA utan NCQ.

Det var dock SCSI som var intressant då disken är det.

Jag kan dock inte spekulera i IDE eller SATA då jag aldrig kört det i raid. Jag kör en Perc 4E DC med 2st Maxtor 15k2-diskar på. Sustained är dubbelt mot diskarna single lite drygt. HDtach visar inte på några höga RATs eller något skumt med söktiden. Kontrollern är en modern PCI-E x8 med moddad cache till 512MByte BBU och stripesize vill jag minnas att jag satt till 256KB för att det fungerade bäst mot mjukvaran i diskarna.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av xAyiDe
Precis, men då är vi ju tebax där vi började. Altså får man ökad transfer med bibehållen söktid?

Nej. Du måste alltid vänta tills du fått datat från den långsammaste disken innan du kan returnera första stripen. Söktiden blir alltså den sämsta av de två diskarna.

Ju fler diskar man hänger på, desto större blir risken att någon av dem maximalt med tid på sig. Med tillräckligt många diskar är den risken 100%, och alltså har vi ökat söktiden. Maximerat den faktiskt, fast det är ju inte positivt i detta fall.

Citat:

Ursprungligen inskrivet av xAyiDe
Du pratar kanske om IDE/SATA utan NCQ eller?

Nej, jag menar hårddiskar i allmänhet.

Citat:

Ursprungligen inskrivet av xAyiDe
Altså en scsi-kontroller använder sortering på alla sina kommandon och read ahead kommer hjälpa dig så till vida att när du vill ha hela filen 128KB kommer den att läsa in de bitar som behövs från de olika diskarna samtidigt. Då får ingen större förlust här. Men att den väntar på nästa blocket stämmer på IDE och SATA utan NCQ.

Vad fint. Det betyder att SCSI-kontrollern kommer ha alla segment av filen som ligger på första disken i minnet redan efter kanske 1.5ms...

Sedan väntar alla, inklusive SCSI-kontrollern, på att andra diskens läshuvud skall hamna rätt och därefter snurra ett halvt varv till så den kan börja läsa, sisådär 6ms senare.

När SCSI-kontrollern sent om sider fått datat kan den pussla ihop bitarna och returnera upp dem till användaren, som i sin tur undrar varför snitt-tiden för att läsa denna typ av filer gått upp.

Vad jag försöker säga är att sortering av kommandon inte spelar så stor roll om du har ett enda kommando i kön, och att read-ahead är ointressant om Disk 1 hinner läsa in hela sin del av filen innan Disk 2 hittat filen.

Jag citerar från Wikipedias beskrivning av Raid 1: (http://en.wikipedia.org/wiki/JBOD scrolla ner till "Raid 1 performance")
"When reading, both disks can be accessed independently and requested sectors can be split evenly between the disks. For the usual mirror of two disks, this would double the transfer rate. The apparent access time of the array would be half that of a single drive. Unlike RAID 0, this would be for all access patterns, as all the data is present on all the disks. Read performance can be further improved by adding drives to the mirror. Three disks would result in three times the throughput and an apparent seek time one third of that of a single drive."

Är det *säkert* att det inte var t.ex. Raid 1 du tänkte på?

Visa signatur

Gammal och gnällig

Permalänk

RAID har ju sin största fördel gentemot single-disk-system när man behöver väldigt många samtidiga slumpmässiga read/write accesser. Det är mkt svårare att få en RAID-kontroller att krokna ihop av för hög belastning, jämfört med att få en single IDE-disk att krokna ihop. RAID används framförallt för att hålla read/write-operationernas tidsåtgång inom vissa tolerabla gränser. Prestandamässigt är det fördelaktigast att ha många små (lite GBs) snabba hårddiskar i RAID-en jämfört med att ha ett fåtal (mycke GBs) långsammare hårddiskar. Klustersize, blocksize och stripesize, ja, det brukar stå rekommendationer i RAID-kontrollerns manualer.

Vid formatering av RAID-en kan det löna sig att välja en klustersize som är större än standard, om man har ett fåtal små filer, och många stora. Det kortar ner operativsystemets behov av att anropa läsning/skrivning. OBS att denna klustersize inte är riktigt samma sak som stripesize etc. Man måste skilja på den hårdvarubaserade RAIDens konfiguration, jämfört mot hur operativssystemet ser filsystemet (partitionen). Lätt att bli förvirrad.

Om NCQ, så är det så att RAID-kontrollern tar själv över kontrollen över att sortera kommandona i en lämplig ordning,, åtminstone hos de bättre RAID-kontr-korten.