Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 144 reacties

Hardwarefabrikant Western Digital zou werken aan harde schijven met een capaciteit van drie terabyte. De schijven zouden in de loop van deze maand op de markt komen, en als interne en externe harde schijven worden verkocht.

Volgens technologiesite Techarp zou Western Digital medio oktober zijn assortiment harde schijven met de 3TB-drives uitbreiden. De schijven worden naar alle waarschijnlijkheid ondergebracht in de Caviar Green-serie, die momenteel schijven met een capaciteit tot 2TB beslaat. De schijven zouden zijn voorzien van Western Digitals Advanced Format-technologie, wat capaciteiten groter dan 2,1TB mogelijk maakt zonder van 32bits-lba-techniek af te stappen.

Bij traditionele sectorgroottes van 512 bytes is de maximumcapaciteit die met 32 bits kan worden aangesproken 2,1TB. Door over te stappen naar sectorgroottes van 4KB vervalt die grens. Een alternatief is een lba-techniek van 48 bits, maar dat wordt alleen door 64bit-besturingssystemen ondersteund, wat de inzetbaarheid van dergelijke schijven beperkt. Seagate heeft al aangekondigd tegen het eind van het jaar schijven van 3TB die van de grotere sectors gebruikmaken te introduceren.

Western Digital waagde zich niet aan dergelijke beloftes, maar Techarp zegt over bronnen te beschikken die zeggen dat de Caviar Black-, Caviar Blue- en Caviar Green-series met 3TB-schijven worden uitgebreid. Ook een aantal externe harde schijven zou een capaciteitsuitbreiding krijgen, net als de mediaspeler WD Elements Play en de nog te introduceren WD TV Live Hub.

Moderatie-faq Wijzig weergave

Reacties (144)

Wat vooral belangrijk is om weten, is wat de vereisten zijn voordat je PC probleemloos met zo'n 3Tbyte HDD overweg kan:

1) Je systeem moet long LBA aankunnen:
  • Je operating systeem kan enkel met long lba werken wanneer het meer dan 32 bit heeft. Windows Vista 64bit, windows 7 64 bit en een aantal linux en mac OS systemen kunnen hiermee werken.
  • Je moederbord moet ook long LBA ondersteunen.
2) Je moederbord moet niet enkel met MBR (Master Boot Partition) overweg kunnen, maar ook met GPT (Gobal Unique Indentifier partition table).

In praktijk zijn er nog zo goed als geen consumenten pc's die met 3tbyte schijven overweg kunnen omdat er amper moederborden zijn die deze herkennen. Moederborden die in plaats van een BIOS een UEFI (Unified Extensible Firmware Interface) systeem hebben, zullen +2 Tbyte HDD's als opstartpartitie kunnen gebruiken.
Momenteel heeft enkel intel zo een reeks moederborden en MSI heeft 1 moederboard ( P45D3 platinum). Asus heeft laten weten om begin 2011 UEFI moederborden uit te brengen. Dus nu naar zo een moederbord zoeken is haast een illusie.

In de server wereld (IBM Blade, Dell PowerEdge, ...) is zulke ondersteuning sneller terug te vinden. Vandaar ook de keuze van Seagate om eerst 3Tbyte harde schijven te maken die bedoeld zijn voor deze markt en pas begin 2011 +2Tbyte HDD's uit te brengen voor de consumenten.

Het enige wat me niet geheel duidelijk is: Volgens mij moet een 3Tbyte HDD in een windows 64 omgeving werken op sommige moederborden, zolang je hem niet als boot partitie gebruikt.

[Reactie gewijzigd door B-BOB op 4 oktober 2010 14:18]

In praktijk zijn er nog zo goed als geen consumenten pc's die met 3tbyte schijven overweg kunnen omdat er amper moederborden zijn die deze herkennen.
Maakt niet uit want wie gebruikt zo'n schijf nu om te booten. Voor data kan het prima.
Het enige wat me niet geheel duidelijk is: Volgens mij moet een 3Tbyte HDD in een windows 64 omgeving werken op sommige moederborden, zolang je hem niet als boot partitie gebruikt.
Nee, er zijn ook 32 bit Windows versies (en ongetwijfeld ook Linux) die ermee kunnen werken:

http://en.wikipedia.org/wiki/GUID_Partition_Table
LBA bestaat alleen in een versies met 48 bits. Ieder huidig systeem gebruikt Long LBA addressing -- anders zou het namelijk nog 28 bits LBA gebruiken en bij 128 GiB al ophouden (ken je 'm nog?).

Het probleem zit 'm niet in LBA, maar alleen in het MBR dat een limiet van 32 bits kent. Het gaat dus puur om het ondersteunen van GPT. 32 bits *nixen kunnen zelfs booten van GPT schijf op een BIOS en uiteraard ook op EFI, Microsoft kan nooit booten van GPT op BIOS, 64 bits post-XP van microsoft kan booten van GPT op EFI. Als data disk kan microsoft overweg met GPT schijven in alle versies (ook 32 bits), behalve XP-32.

http://en.wikipedia.org/w...n_Table#OS_support_of_GPT
Ik als leek ben wel benieuwd wat de voor/nadelen zijn van grotere sectorformaten. Is het niet zo dat kleine files dan in verhouding ook veel meer ruimte gaan gebruiken? De vraag is dan hoeveel extra ruimte je nodig hebt voor dezelfde files.

Anders krijg je net zo'n vergelijking als 4GB RAM: in een 32-bit systeem kan je maar 3,5GB RAM aanspreken. Als je dan overstapt naar een 64-bit besturingssysteem kan je de 4GB wel volledig aanspreken, maar door de grotere footprint van de 64-bit DLL's ben je die extra halve GB eigenlijk alweer kwijt.

[Reactie gewijzigd door Luuk1983 op 4 oktober 2010 10:18]

OT: op een 32-bit systeem kan je in theorie per applicatie 4 GB RAM aanspreken (32 bit address space). Het feit dat Windows slechts 4 GB RAM ondersteunt (of zelfs 3,5 GB) is een licentiebeperking. Dit zie je bijvoorbeeld aan het feit dat je met 32-bit Enterprise/Datacenter edities van Windows Server 2008 tot 64 GB RAM kan gebruiken -- maar uiteraard slechts 4 GB per applicatie wegens 32-bit address space limitaties. Omwille van allerlei technische redenen wordt de 4 GB per applicatie dan weer opgesplitst in 2 keer 2 GB slices (stukje user/kernel) of zelfs 3 GB/1GB (speciale bootflags) zodat je in een applicatie feitelijk maximaal 2GB aan data kan "inladen".
Nee dat klopt niet.
a byte-addressable 32-bit computer can address 232 = 4,294,967,296 bytes of memory.
Popular Intel Pentium processors since introduction of Physical Address Extensions (PAE) support 36-bit physical addresses, while generally having only a 32-bit word.

32 bit komt niet verder dan 4 GB, daarboven heb je echt minimaal 36 bit nodig!
Je hebt volledig gelijk - PAE geeft 36 bits, dus 2^36 = 64 GB adresseringsruimte, oftewel de maximale limiet die je op het 32-bit besturingssysteem "Windows Server 2008 Enterprise Edition" kan gebruiken. Ik had wat kort door de bocht de woorden "32 bit systeem" in de mond genomen zonder over PAE te spreken (bon, ik ben ook niet echt expert terzake).

Gelukkig hebben we bijna allemaal al een hele poos processoren met PAE support en maakt het in de praktijk niet zoveel uit :).
Wat een klestverhaal... 32bit systeem bekent gewoon 4GB voor het totale systeem. En aangezien je naast je applicaties ook ruimte nodig hebt voor je OS én je hardware, heb je dus beduidend minder voor je apps.

In Windows is je totale geheugenruimte standaard in tweeen met 2GB apps en 2GB OS + hardware. Je kunt ook een 3:1 verhouding krijgen. Dat werkt op desktops i.h.a. niet, vanwege de enorme geheugens van videokaarten. Die 1GB videokaart gaat ook gewoon van die 4GB totaal af!!! Dus die 2GB opsplitsing is helemaal niet zo raar!

64GB haal je alleen via PAE, hetgeen een workaround is, waarbij je een grote geheugenbus toelaat, terwijl je toch maar een 32bit systeem hebt. In zekere zin vergelijkbaar met de EMS methode die in het DOS tijdperk gebruikt werd. Dergelijke omslachtige methoden wil je uiteraard liever niet gebruiken... Vergt ook specifieke code. Veel logischer om gewoon naar een 64bit OS te gaan.
Zoals ik elders al zei, ik bedoelde 32bit OS ipv 32bit systeem (hardware). Op 32 bit OS's kan je dus perfect meer dan 4 GB aanspreken door PAE te gebruiken en de licentiebeperkingen van Microsoft te omzeilen:

http://www.microsoft.com/...rm/server/pae/paemem.mspx

http://www.raymond.cc/blo...ort-more-than-4gb-memory/
Ach so. Nu begrijp ik ook waarom videokaarten steeds meer geheugen krijgen, omdat er maar 2GB per app gebruikt kan worden van het interne geheugen.
Integendeel! Videokaartgeheugen moet mee in de 32bit adressspace. Dus 1 gig video ram limiteert de overige ram de 3gig
Eh nee niet echt. videogeheugen kan niet gebruikt worden zoals normaal intern geheugen wordt gebruikt. Dit type geheugen is volledig gericht op beeldberekingen van de gpu, textures etc. Tegenwoordig ook voor physics en andere zaken, maar dit is omdat een videokaart beter floatingpoint berekeningen kan doen dan een gewone cpu.
De textures stonden vroeger in het RAM (toen had je nog 16 mb geheugen op je grafische kaart) en kunnen tegenwoordig in de gpu (zoals je zelf aangeeft). Dus zo gek is de opmerking van twilight niet.

[Reactie gewijzigd door sdk1985 op 4 oktober 2010 21:03]

Het geheugen op de video kaart is vaak sneller en beter geschikt voor het werk wat er mee gedaan word dan het generieke geheugen waar de rest van het systeem mee werkt.
Ik als leek ben wel benieuwd wat de voor/nadelen zijn van grotere sectorformaten.
Als je nieuwsgierig bent naar performance verschillen tussen 512byte & 4KB HDDs, neem dan eens een kijkje naar Toms Hardware review & benchmarks hierover : http://www.tomshardware.c...rmat,review-32012-12.html

Hun opzet is als volgt:
We took two of the latest Toshiba 2.5” SATA hard drives to compare performance between 512 byte and 4 KB sector size and to look at what happens in a worst case, as older system environments may deliver decreased performance on 4 KB sector drives. This would apply to all 4 KB drives, hence the two products we’re using should be considered exemplary.
De verschillen zijn minimaal, maar neem ze wel met een korreltje zout, want de twee modellen die ze testen hebben een verschillende data-densiteit (in het voordeel van de 750GB 4KB schijf)
Ik als leek ben wel benieuwd wat de voor/nadelen zijn van grotere sectorformaten. Is het niet zo dat kleine files dan in verhouding ook veel meer ruimte gaan gebruiken?
Nee, want je NTFS cluster size (gegeven dat je Windows gebruikt) is sowieso 4 kb (default).

Daarnaast worden kleine files onder NTFS op een andere manier opgeslagen (geclusterd), maar dat terzijde.
Ik meende al dat de 2TB grens een probleem was van 28 bits LBA.
Maar Western Digitals Advanced Format-technologie is dus een oplossing voor een probleem dat pas bij 32TB optreedt. Beetje een wassen neus.
Ik meende al dat de 2TB grens een probleem was van 28 bits LBA.
Maar Western Digitals Advanced Format-technologie is dus een oplossing voor een probleem dat pas bij 32TB optreedt. Beetje een wassen neus.
Fout. OM FAQ

28bits LBA was een probleem rond de eeuwwisseling. De limiet met 28bits LBA is 128GB.

Toen kwam er support voor 48bits LBA. Probleem is dat een aantal operating systems wanneer ze op een 32bits CPU draaien ook maar 32bits LBA kunnen gebruiken. Ik geloof dat Linux daar trouwens geen last van heeft.

28bits is goed voor 128GB, 29bits 256GB, 30bits 512GB, 31bits 1TB, 32bits 2TB.
Toch heb ik een raid controller (promise sx6000) waarbij ik maar drives van 2TB kan maken als gevolg van de 28 bits LBA. (ik kan wel hdd's gebruiken met 32 of 48 bit LBA, maar de controller kan maar drives maken met een 28bit LBA en met 4k sectoren komt dat wel degelijk uit op 2TB.)

De praktijk bewijst dat de genoemde FAQ heeft het fout heeft.
edit:
Ik zie het al, de FAQ vergeet te melden dat dat alleen voor IDE-schijven geldt. mijn controller doet zich voor als SCSI
Toch heb ik een raid controller (promise sx6000) waarbij ik maar drives van 2TB kan maken als gevolg van de 28 bits LBA. (ik kan wel hdd's gebruiken met 32 of 48 bit LBA, maar de controller kan maar drives maken met een 28bit LBA en met 4k sectoren komt dat wel degelijk uit op 2TB.)
Daarmee geef je dus precies aan dat het klopt. 28bits LBA icm. sectoren van 512 bytes geeft een maximum van 128GB. 32bits LBA icm. sectoren van 512 bytes maximaal 2TB. 32bits LBA icm. 4KB maximaal 32TB.

De introductie van 4KB sectoren door WD (wat je normaal zonder speciale raidcontrollers zoals die van jou niet voor elkaar krijgt) was hier dus een noodzaak om met 32bits LBA te kunnen werken.

[Reactie gewijzigd door W3ird_N3rd op 4 oktober 2010 19:26]

FAT32 is 4k, NTFS 512b default...toch?
De Default cluster size is bij NTFS momenteel 4kB.

http://support.microsoft.com/kb/314878
Hier een leuk artiekel over 3tb schijven en wat daar bij komt kijken

http://www.bit-tech.net/h...eady-for-3tb-hard-disks/1
Betekend dit dan ook dat de ruimte in efficient gebruikt wordt? Veel ruimte wordt verspild omdat eens sector niet volgezet kan worden? Of zit ik nu op een klop - klepel spoor.
Dat klopt ja. Je krijgt meer ruimte die je niet kunt gebruiken, omdat maar een deel van een sector gebruikt wordt.
Als je de schijven gaat gebruiken voor de opslag van grote files dan ga je hier bijzonder weinig van merken. Maar als je er een OS op draait dat bijv veel kleine configbestandjes heeft van een paar bytes dan ga je dit wel sneller merken.
In dat geval kun je beter een kleinere disk pakken.
Sowieso is het volgens mij nog niet mogelijk om met een normaal (niet-EFI) moederbord te booten van volumes die groter zijn dan 2 TB (GPT partities o.i.d.?). Dus waarom je een 4KB-sector disk als OS-disk zou willen is mij onduidelijk. Daarbij komt nog dat bij disks waar de 4KB-sectors gebruikt worden eigenlijk altijd grote disks zijn, waar 100MB meer of minder niet veel uit zou moeten maken.
Ach, we gaan er toch naartoe naar speciale bootdisks en opslagdisks. SSD's zijn er niet voor niets op de markt =D Hier ook; een SSD+ 2TB aan harde opslag. In laptop zie je ook steeds meer SSD's verschijnen.
Volumes ja, dus als je een boot- of systeem-partitie maakt die kleiner is dan de hele schijf, probleem verholpen...
Ik vermoed dat je zelf maar weinig bestanden kleiner dan 4KB maakt. En die 5-10GB van je OS (wat wel nog vele kleine bestanden gebruikt) maakt op 3TB echt niet meer uit...
Ook files groter dan 4KB verspillen ruimte - de grootte van files moet je omhoog afronden naar een veelvoud van de clustergrootte. Een file van 4,1kb neemt dus 8kb in op een schijf met 4kb clusters.

Dat gezegd hebbende, zoveel ruimte zul je niet verliezen dat je er last van hebt.
Mijn C schijf bevat Windows, Program Files, en wat spellen, en daarmee ongeveer 93000 files. Gemiddeld zul je de halve clustergrootte kwijtraken per file, dus 2K per file als je over 4KB clusters praat: dat is ongeveer 180 MB aan verloren ruimte. Veel, toen we nog met 486s werkten, maar nu niet heel relevant meer.

Overigens zul je juist door je Windows folder en je temporary internet files een hoger verlies zien dan 50% van je clustergrootte (vanwege heel veel kleine bestandjes). de 93000 files op mijn C schijf zijn 71076M groot en nemen 71263M in op de schijf, een verlies van ~210MB

[Reactie gewijzigd door KnetterGek op 4 oktober 2010 10:36]

maar 4kb is nou net de def. siz van ntfs, dus je merkt er 0 van
Maar mocht je toch een kleinere size gebuiken, dan kan je de 3TB altijd nog in emulation mode aansturen. Dan worden er 8x 512bytes in een 4k sector geplaatst. Een kanttekening is wel dat als je dan een van de 'virtuele' sectoren wil aanpassen, altijd de gehele 4k sector herschreven moet worden maar aangezien je toch geen delen van sectoren kan schrijven (crc moet altijd opnieuw berekend worden) zal dat in de praktijk niet veel uitmaken.
Het is wel zo dat het correcte allignment belangrijker is voor performance dan bij kleinere sectoren.
Maar mocht je toch een kleinere size gebuiken, dan kan je de 3TB altijd nog in emulation mode aansturen.
De schijf kan alleen maar in emulation mode, niet in emulation mode is geen optie. Schijven die naar buiten toe 4k zijn komen naar verwachting pas in 2014.
Nee. De schijf die in dit artikel wordt beschreven doet GEEN emulatie mode. Emulatie mode doorbreekt de 2TB/LBA32 grens niet. Wat er gezegd wordt is de 3TB kan worden aangesproken met LBA32, en dat betekent dus dat de externe logische sectoren minstens 768 bytes zijn, en dus hoogstwaarschijnlijk gewoon 4kB.
Nee. De schijf die in dit artikel wordt beschreven doet GEEN emulatie mode. Emulatie mode doorbreekt de 2TB/LBA32 grens niet.
Niet onder NTFS MBR nee, maar wel bij gebruik van GPT (wat een groot aantal Windows versies kan). Er wordt nergens gezegd dat het WEL onder MBR werkt.
Wat er gezegd wordt is de 3TB kan worden aangesproken met LBA32, en dat betekent dus dat de externe logische sectoren minstens 768 bytes zijn, en dus hoogstwaarschijnlijk gewoon 4kB.
Dat wordt in het artikel i.d.d. gezegd, maar dat is slechts gebaseerd op geruchten. De feiten zijn dat er tot nu toe alleen beweerd is door de HDD fabrikant(en) dat echte 4k sectoren (naar buiten toe) pas in 2014/2015 zullen komen.

[Reactie gewijzigd door grizzlybeer op 4 oktober 2010 17:34]

Tja, als hij naar buiten toe toch weer 512 is dan zal dat dus betekenen dat je hem alleen onder GPT kan gebruiken, en dus in de praktijk niet er van kan booten.
In de praktijk maakt het niks uit. De meeste filesystems hebben een blocksize van 4KB. NTFS, Ext3, Ext4... allemaal gebruiken ze standaard 4KB of een veelvoud daarvan.
Wanneer je 3TB volzet op een enkele schijf hoop ik dat het wat grotere bestanden zijn waarbij slack van <512 byte te verwaarlozen is. Dikke kans dat je clustergrootte dan toch al hoger ligt.
Als je 3TB vol zet met bestanden van minder dan 4kB dan heb je 750 miljard bestandjes. Als je die moet uitlezen zakt je snelheid zo in dat je je HD al lang met een hamer wil bewerken.
Je raakt gemiddeld, per bestand 1,75kB kwijt (als je niet al 4kB sectors gebruikte). Op een 3TB disk niet zo'n heel groot probleem ;)
Ik heb 55.000 files op mijn bootschijf, dus dat komt neer op zo'n 100MB extra slack-space bij 4kB ipv 512byte sectoren.

Maar je zou natuurlijk ook sectoren van 1KB kunnen gebruiken, dan kun je schijven tot 4TB adresseren.
Ik had toch verwacht dat ze nu wel over zouden stappen op 48bits technieken. Een 64bits besturingssysteem wordt steeds meer gebruikelijk nu ook in office-pc's al 4GB ram gestopt wordt.

Maar dit gaat wel een mogelijke vervanger worden van de berg kleinere hdd's die ik nu in m'n pc heb. Twee van deze in RAID 1 en ik kan voorlopig weer vooruit!
hmm ik zou deze niet in RAID zetten als ik jou was...zeker geen RAID0. als die crashed, ben je 6TB aan data kwijt :P
Eh? :?
Sorry dat snap ik niet. Eerst zeg je dat je beter geen RAID kunt gebruiken, en vervolgens heb je het over mogelijk dataverlies? Wat dacht je dat de bedoeling van RAID is (en dan heb ik het niet over RAID 0, dat is eigenlijk geen echte RAID vandaar ook de '0')?
Daarom heb ik het ook over RAID 1 (mirror) dan kan er een crashen en ben ik (in theorie) niets kwijt :).

RAID0 heb je bij deze schijven denk ik niet veel aan. Wie zal er 6TB over 1 partitie verdelen? Ik niet in iedergeval, al is het alleen maar vanwege de lastigheid om de schijf dan opgeruimd te houden. Tenzij je alleen maar werkt met FullHD filmmateriaal ed. Maar dan lijkt het mij dat je toch al een dikke NAS hebt staan.
heb hier gewoon 5, 2tb schijven in raid 5 als 1 grote disk.
lijkt mij toch makkelijker dan dat je 6 partities gaat aanmaken voor van alles....het sharen over een netwerk is dan ook nietecht makkelijk.

dus natuurlijk ga je juist wel schijven in raid als 1 partitie maken.
het zijn opslag schijven dus is dat nu juist de mogelijkheid.

neemt niet weg dat raid 0 natuurlijk nietecht handig is voor data opslag.
48 bit LBA wordt ook al lang door 32 bit besturingssystemen ondersteund.

Daar is echt geen 64 bit OS voor nodig.

http://www.48bitlba.com/
De ouderwetse partitietabel ondersteunt maar LBA tot 32, en daar zit hem de kneep. GPT ondersteuning is sowieso marginaal (as in geen boot) en daarnaast losjes gekoppeld aan 64 bits versies.
De vraag in deze discussie is dus of "de ouderwetse partitietabel" onderdeel is van het FS of het OS.

Er is toch geen recente versie van NTFS die verder gaat dan 32?
Vanaf Vista of mogelijk 7 ondersteunt Windows GPT partitionering ipv MBR, en die kan wel weer tot zoveel yottabytes ofzoiets mee. Je kunt alleen niet booten van GPT zonder dat je UEFI hebt ipv een BIOS, en dat heeft vrijwel niemand nog.

Gelukkig is de trend voor SSD boot + rotating storage, daarmee kunnen we nog weer even vooruit.
Inderdaad, toen met de eerste Xbox hebben ze uiteindelek ook de kernel geupdate naar LBA48 om hdd boven de 137GB aan te kunnen spreken.

"The actual limit with 28-bits is a maximum of 268,435,456 sectors of 512 bytes of data or 137.4 gigabytes. With 48-bit addressing the limit is 144 petabytes (144,000,000 gigabytes)."

"The next capacity barrier will come sooner than that at 2.2 terabytes (2,200 gigabytes) because many of today's operating systems are based on 32-bit addressing."
48 bit LBA wordt ook al lang door 32 bit besturingssystemen ondersteund.

Daar is echt geen 64 bit OS voor nodig.
Zie dit artikel:

http://www.techarp.com/showarticle.aspx?artno=682&pgno=0

De limiet van 2(,1) TB moet dus te maken hebben met NTFS. Probleem is dat dit vrijwel nooit besproken wordt, want:

1) NTFS is ongeveer het default FS (dus er worden doorgaans geen alternatieven besproken)
2) Hoort het nu wel of niet bij het OS (m.a.w. als NTFS geen > 2 TB aankan kan je dan zeggen dat het OS het niet kan)

Mijn conclusie is dat er voor deze 3 TB schijven sowieso GPT nodig is (voor Windows dan), en dus (U)EFI als je van de schijf wil booten.
Ik vraag me wel af hoeveel nut het heeft om 4kb sectors te hebben.
WindowsOS gebruikt ook zoiets en dan is een bestand van 2kb op de HDD 4kb.
Als je veel kleine bestanden hebt (websites) benut je nooit de volledige 3TB.

Daarentegen is het wel handig voor grote bestanden. Dus lijkt me een HDD die vooral geschikt is voor media (foto's, film, audio).
Ik vraag me wel af hoeveel nut het heeft om 4kb sectors te hebben.
De 4 kb sectoren hebben ook geen nut voor de eindgebruiker. Zij zorgen er voor dat schijven > 2 TB uberhaubt mogelijk zijn. Daarnaast is er bij AF ook sprake van een verbeterde foutcorrectie.
Het lijkt me ook niet erg logisch om een 3TB HDD als boot device of webserver te gaan gebruiken. Aangezien deze schijven hoofdzakelijk worden gebruikt voor grotere data opslag, zouden ze de clustergrootte zelfs kunnen verhogen om zo nog grotere HDD's te kunnen maken. Maar dan moet de koper daar natuurlijk wel van op de hoogte zijn. Hoewel je dan nog niet erg veel ruimte verspilt, want een extra TB erbij compenseert dat weer dik en dubbel.
Als je het verhaal had gelezen is die 4KB nodig om schijven groter dan 2,1TB te produceren. Dus reuze nuttig! Daarbij produceer je met 4KB bestanden minder overhead en is overstappen op 48bit LBA niet handig aangezien alleen 64bit OS systemen daarmee overweg kunnen.
heeft iemand enig idee of er al enige prijsindicatie was opgegeven voor deze schijven ? Ik wacht hier al een heel poosje op. Ik heb echt gigantisch veel ruimte nodig om in mijn download behoefte te voorzien en backups te draaien van mijn huidige data. Ik heb tot nu toe niks kunnen vinden over prijzen.
Gezien de prijzen van 2TB en de natuurlijke opslag van nieuw produkt ;) zou ik zelf verwachten dat ze rond 160/170 euro uitkomen. In het begin een dus iets hogere prijs per GB dan de 2TB serie.
Denk eerder 200.

Waar ik erg benieuwd naar ben is of dit vijf platter schijven worden (zoals de enige 3TB drive tot nu toe) of vier platter schijven. Op dit moment zijn de grootste platters 666GB, voor drie platter 2TB. 600 x5 is stukken minder interessant dan 750 x4 zou zijn.
Hier ben ik ook benieuwd naar.

Sowieso wat lager dan 200 euro gok ik, gezien de prijs van de externe variant van Seagate:
- nieuws: Seagate introduceert externe harde schijf van 3TB
- http://www.ffxs.net/?p=790
- http://nl.hardware.info/n...et-externe-schijf-van-3tb

Overigens ben ik wel benieuwd naar de verhoudingen tussen de 48-bit LBA van Seagate en de methode die WD gebruikt om de 2.1TB limiet te doorbreken (clusters vergroten).

[Reactie gewijzigd door Chocola op 4 oktober 2010 14:56]

Overigens ben ik wel benieuwd naar de verhoudingen tussen de 48-bit LBA van Seagate en de methode die WD gebruikt om de 2.1TB limiet te doorbreken (clusters vergroten).
Theoretisch zal het iets sneller zijn.
vroeger bij 4K schrijven:
zal er 8 keer een 32 bit adres over de lijn gaan, met 8 keer 512 byte data ( en na elk blok nog wat extra metadata. )

WD:
er gaat nu 1 adress van 32bit over de lijn gaan, en daarna 4K data.

seagate:
er dus 8 keer 48bit over de lijn gaan als adres met 8 keer 512 byte data


logica zegt dus dat de WD manier sneller is.

verder sluit 4K ook beter aan bij default ntfs/ext3 en 4
wil dit zeggen dat wij een +/-2.5TB schijf dan eigenlijk krijgen? Al die marketing rommel vertrouw ik voor geen haar meer ... 3TB is 3TB en geen KB minder... Wat ze technisch ermee doen lijkt me voor de consument niet bepaald een argument om minder te krijgen.
In de natuurkunde betekenen de termen Kilo, Mega, Giga en Tera al eeuwen respectievelijk duizend, miljoen, miljard en biljoen.

Vervolgens zijn er een paar computernerds in de jaren 60/70 die termen verkrachten tot 2^10, 2^20, 2^30 en 2^40 en daarna gaan hele volksstammen de officiële betekenis ineens 'marketing rommel' noemen. Heel vreemd.

Nog één keer voor de duidelijkheid:
TB = 1.000.000.000.000
TiB = 1.099.511.627.776
Dat is inderdaad de theorie, alleen is TiB geheel niet geaccpeteerd in de industrie. Persoonlijk ben ik deze notering alleen nog hier op Tweakers.net tegengekomen.
Dat doet er niet toe. De harde schijf fabrikanten en ook fabrikanten van netwerkapparatuur doen het goed. Ze geven zelfs altijd aan hoe ze het berekenen. Op elke specificatiespagina op de websites van harde schijffabrikanten staat onderaan wel iets in de trant van 1 GB = 1.000.000.000 bytes. Ik heb een tijd Technische Informatica gestuurd en daar werd het in veel boeken ook goed gedaan.

De reden dat het niet geaccepteerd wordt ligt voor een groot deel bij Microsoft, zij doen het namelijk al jarenlang fout met Windows en dat is wat de meeste mensen zien. Zij zien bij Deze Computer dat de harde schijf niet zo groot is als in de specificaties stond.

Sommige Linux distributies doen het volgens mij wel goed, ik dacht dat Ubuntu daar één van was.

Consumenten klagen nu iedere keer over de fabrikanten van harde schijven dat ze de boel oplichten, terwijl het aan onder andere Microsoft ligt. Seagate heeft een keer aan de klachten toegegeven en een rechtzaak geschikt, erg jammer vind ik, want ze deden niks fout. (nieuws: Seagate wil aanklacht over grootte van gigabyte schikken)
Toen de schijven nog ongeformatteerd werden verkocht was het de bruto ruimte. Afhankelijk van de manier van formatteren leverde het veschillende netto waardes op.
Met PC/M anders dan LBA en zo is het eigenlijk nog steeds.

Tegeswoordigs staat het netjes op het stickertje op de schijf dat men van 1.000.000.000 uit gaat.
Mac OS X 10.6 doet het ook goed: 250.06 GB (250,059,350,016 Bytes)

Deed Windows het niet ook goed sinds 7 ?
Nope, Windows 7 Professional (volledig up-to-date) herkent mijn 1 TB schijven als 931 GB.
Ubuntu Schijf /dev/sda: 120.0 GB, 120034123776 bytes

Versie: 2.17.2-0ubuntu1

Wel een gepatchte versie dus, maar of dat hierin zit?
Hoeveel bytes is die 4KB?
En dan nog alleen bij harde schijven. Bij RAM is iedereen het ineens weer vergeten, 1 GB RAM is gewoon 2^30 bytes RAM.
Sterker nog, de RAM cache in harde schijven wordt ook gewoon in MB opgegeven, moet dat geen MiB zijn?

[Reactie gewijzigd door Free rider op 4 oktober 2010 11:53]

TiB is inderdaad niet geaccepteerd door de industrie maar had eigenlijk wel de standaard moeten zijn naar mijn mening. Ik heb vroegâh altijd geleerd dat er 8 bit in een byte zitten en 1024 bytes in een kilobyte enz. Alle software werkt met deze methode dus waarom voor de computerindustrie niet? Dan ga ik bijna geloven dat het wel een marketing dingetje is geworden.
Waar het fout ging is toen de kibibyte niet meer voldeed als prefix om heel veel cijfers te voorkomen. De kibibyte werd namelijk nog wel 'goed' gedaan in zoverre dat er onderscheid was tussen het standaard SI prefix kilo en de kilo prefix in de computerwereld. De kibibyte (die eigenlijk wel vrijwel altijd kilobyte werd genoemd) had namelijk de prefix K, terwijl de SI prefix kilo de k gebruikte.

Bij mega ging dat niet meer, want dat was al een hoofdletter en de kleine letter werd ook al gebruikt voor de prefix milli. Dit resulteerde in drie verschillende 'mega prefixes', namelijk 2^20, 10^6 en 1024000.
De maten met "i" bestaan gewoon nog maar een paar jaar. Over twintig jaar worden ze gebruikt.
Je zult 3 TB krijgen met zo'n ding (en da's ongeveer 2.72 TiB). Helaas wordt meestal TB gebruikt wanneer er TiB bedoeld wordt...
Ik geef je gedeeltelijk wel gelijk. Ze zetten 3TB op de harde schijf, terwijl het eigenlijk 3.000.000.000.000 bytes zijn (2,5TB). Dat ze dan ook 2,5TB op de HDD schrijven en niet 3TB, want dat vind ik wel misleidend. Je weet nooit wat je daadwerkelijk een capaciteit krijgt wanneer je hem koopt. Pas nadat je hem geformatteerd hebt zie je hoeveel TB je echt hebt.
Aan de andere kant...een beetje een ervaren PC gebruiker weet dat hij minder krijgt dan die 3TB.
Aan de andere kant...een beetje een ervaren PC gebruiker weet dat hij minder krijgt dan die 3TB.
Nee, je krijgt exact 3TB. Dat wordt hierboven al uitgebreid uitgelegd.

Tera betekent 1.000.000.000.000 = 10004
Dus 1 terabyte is 1.000.000.000.000 byte = 10004 byte
3 TB is 3.000.000.000.000 byte = 3 * 10004 byte

Alleen, jij verwacht helaas dit:

3 * 10244

Dit heet geen 3TB, maar 3 TiB.

Als je laatstgenoemde echt zou krijgen heb je dus:

3 TiB = 3 * 10244 = 3.298.534.883.328 byte = 3.30TB

Dat jij 3TiB verwacht terwijl de fabrikant gewoon 3TB belooft (en ook levert) is jouw probleem. En Windows zet je ook op het verkeerde been omdat het TB opgeeft terwijl het eigenlijk TiB is.

[Reactie gewijzigd door Bonez0r op 5 oktober 2010 14:29]

Mac OS X heeft sinds Snow Leopard (10.6) om die reden de "natuurkundige" berekening overgenomen, waardoor je schijf na een upgrade ineens groter leek ;) Maar het scheelt wel een hoop verwarring als je eenmaal gewend bent dat ook de bestanden die je erop zet wat groter zijn. Mijn 160 GB SSD is dan ook 160 GB :)
Maar als je grote files gaat downloaden dan pakken ze weer groter uit op een Mac OS X systeem, dus totdat iedereen op dezelfde manier gaat rekenen blijft het lastig.
3 TB is 3 miljard bytes

2,79 TiB ongeveer.
giga is miljard, tera is biljoen
Zal wel iets meer overblijven hoor. Ik denk dat deze stap 2,5TB en 3TB schijven zal brengen en die zullen in praktijk misschien 0,2-0,3 TB kleiner zijn?
3TB op 1 schijf is wel erg veel.
Dit is natuurlijk handig dat je maar 1 schijf hebt, minder stroomverbruik, minder geluid enz.

Maar aan de andere kant, als een schijf crasht (dat gebeurt nog al eens een keer) ben je alles kwijt.
Is het dan niet verstandiger om een paar kleinere te hebben?
Als je twee schijven zou hebben, dan ben je inderdaad maar de helft van je data kwijt, maar de kans dat er één schijf stuk gaat is dan ook twee keer zo hoog, dus niet echt een verbetering.
Dat is niet hoe raid 1 (spiegelen) werkt. Je schrijft je informatie weg op de ene schijf en tegelijk nog eens op de andere. Je slaat je data dus dubbel op. Als een schijf dan uitvalt ben je geen informatie kwijt, alleen de kopie van je data.

Nog beter is een externe machine en een rsync-oplossing, maar gespiegelde schijven beschermen je iig alvast tegen mankementen in de schijven zelf.
Ik ben zelf geneigd om na de eerste twee schijven eens per jaar nog een schijf bij te pluggen omdat hdd's historisch vooral in de eerste zes maanden of in de laatste twee jaar van hun levenscyclus (vijf jaar) uitvallen.
Hoe groter de schijven worden bij gelijkblijvende prijzen per MB, hoe interessanter een raid 1 array wordt. Je hebt immers steeds minder kastruimte nodig voor het zelfde aantal TB's, maar als een niet gespiegelde WD van 3TB de geest geeft ben je veel meer informatie kwijt dan met een schijf van 500GB.
Je kunt er twee nemen en ze spiegelen (raid 1) met software raid. Intel biedt een geïntegreerde oplossing in de vorm van hun ichr controller. Intel is meestal vrij vlot met de ondersteuning en wd's overstap van eads naar ears heeft daar al geleid tot aanpassingen ten behoeve van de ondersteuning van +2TB arrays. Ik kijk zelf de kat nog even uit de boom.
Software & geïntegreerde raid oplossingen zijn ook geschikt voor raid 10 maar wacht reviews af om te zien of dit met deze schijven ook snelheidswinst oplevert.
Overweeg je raid 5, wacht dan op een geverifieerde hardware oplossing die deze schijven ondersteunt, waarbij je voor de snelheid je arrays best inricht in groepen van 3 of 5.
Wat je ook doet, blijf met je schijven uit de buurt van jmicron chips, paarse poorten op een gigabyte bord, smart backup enz. En gebruik voor een software raid op deze schaal alleen een 64bit-besturingssysteem, ongeacht wat wd verzint.
Overbodig om te zeggen dat het gestoord is om te stripen (raid 0) en met dit soort formaten helemaal.
Volgens mij heb je wel gelijk, alleen hoe relevant is dit? Sectoren met een grootte van 4KB kan 3 * 1024^4 / (4 * 1024) is een kleine 800 miljoen. Het aantal kleine files op een file systeem zal in normale omstandigheden een klein fractie hiervan zijn, maw je zult er niet zoveel last van hebben.


Note: de berekening gecorrigeerd. Initieel stond een berekening voor 3GB ipv 3TB.

[Reactie gewijzigd door mcmd op 4 oktober 2010 13:02]

Doe er maar zeker een factor 1000 bovenop, het zijn er heus veel meer dan 800.000.
Je kijkt nu naar Gibibytes, je moet kijken naar 3 * 10^12 voor Terabytes.

Je komt dan dus uit op 3 *10^12 / 4096 = 732421875 bestanden

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True