'Long Block Data'-standaard moet harde schijf versnellen

Een nieuwe standaard voor geheugenblocks op harde schijven moet bij toekomstige modellen zorgen voor een snellere data-overdracht. Dit moet bereikt worden door blocks van 512 byte naar 4.096 byte te vergroten.

De nieuwe Long Block Data (LBD)-standaard is door de Idema-werkgroep goedgekeurd. De LBD-techniek moet het dertig jaar oude systeem van 512-byte-blokken aflossen. De organisatie belooft naast verbeterde lees- en schrijfprestaties ook een tot tien maal lagere foutfrequentie. Diskintensieve handelingen als formatteren en defragmenteren zouden ook rapper verlopen. Nadeel van de verhoogde blokgrootte is de toename van niet gebruikte ruimte, omdat ook een bestandje van enkele tekens groot toch 4.096 bytes zal opslokken. Gezien de gestaag toenemende capaciteit van harddisks lijkt dit echter nauwelijks een probleem te zijn.

Idema denkt dat de nieuwe LBD-standaard, die backwards compatible is, in 2010 gemeengoed zal zijn. Seagate en Western Digital zullen in de tussentijd schijven gaan aanbieden die gebruik maken van acht continue 512 byte blocks. Zo kan de 512 of de 4.096 byte-standaard gebruikt worden. Windows Vista en recente versies van Linux ondersteunen de LBD-standaard al.

Reacties (72)

[MaxxMark]

Ik snap eigenlijk niet waarom ze niet meteen ook voor nog grotere block's gaan?

Als het 'toch geen probleem' zal zijn dat je 4kb per file standaard kwijt bent dan al 8 of 16kb ook geen probleem zijn.

Zou het dan niet handig zijn om meteen dergelijke grootte's te gaan ondersteunen, in plaats van eerst te wachten totdat de 4k 'te klein' is?

[.oisyn]

Omdat de pagesize op veel hedendaagse CPUs ook 4k is. Als je grotere HD blokken zou maken, zou dat betekenen dat je niet meer makkelijk individuele pages kunt lezen en schrijven - dan moet je óf een virtuele page als meerdere fysieke pages gaan behandelen, óf je moet lezen/schrijven naar een leeg stuk geheugen en alleen het relevante deel naar de juiste plek kopiëren

[Iblies]

Als je een idee hebt hoeveel kleine bestanden windows in gebruik heeft, en hoe sommige spellen textures misbruiken door van elke texture een filetje te maken, dan lijkt me 16 kb nog te veel en ook 8kb is ook overkill.

[MaxxMark]

Dan nog kan je zeggen dat je bijv je windows installatie op een andere schijf hebt staan en bijv video files altijd op een andere schijf. Zeker daar valt (denk ik) veel snelheid te behalen met het gebruik van (veel) grotere block sizes.

Ik zit me nu af te vragen in hoeverre block sizes invloed hebben op bijv database files. Deze worden ook vaak heel groot, maar ik vraag me af in hoeverre dat invloed op elkaar heeft..

[ultimasnake]

Vergeet niet:
Niet iedereen heeft de luxe tot het kopen van 2 schijven, of voor hen is het zelfs niet nuttig

En volgens mij is het JUIST sneller voor VEEL kleine bestanden ipv 1 groot bestand gok ik zo .

[Darkprince1234]

luxe? kom nou... 80 euro voor een 320gig schijfje, en 98 voor een 500gig schijfje.... niet bepaald luxe hoor.

TIP: Het is een kwestie van kiezen voor net niet alles van het beste en dan een extra schijf of 2 nemen van het geld dat overblijft hierdoor.

[humbug]

Vertel eens, hoe bouw ik een 2e harddisk in in een UMPC? Niet iedereen heeft een grote desktop om vol te stouwen met rotzooi....

[StackMySwitchUp]

Dat kan wel zo zijn, maar de 512b clusters stammen nog uit de 70-80's
Als je kijkt naar de grootte van harddisks toen (2 MB-30 MB) en nu (500 GB - 1TB) dan zou je de cluster grootte in zekere zin ook incrementaal kunnen vergroten (nu is dit bij een 500 GB schijfje toch wat overkill om er clusters van 512 KB in te stampen)
maar dan is het voorbeeld wat MaxxMark met 16 Kb zegt, toch vrij realistisch.

[mae-t.net]

De 512B clustergrootte stamt uit de tijd van IDE en LBA, dan heb je het dus over (begin) jaren '90, nog vroeger had je harde schijven die je in het BIOS of nog eerder op de controller zelf geheel moest instellen.

[froggie]

Het zal vast mogelijk zijn een filesystem aan te passen zodat deze meerdere kleine files in een block kwijt kan. Op die manier zou je het verlies in opslagruimte weer kunnen goedmaken. Dit zal wel de consequentie hebben dat je filesystem meer werk heeft om dingen weg te schrijven waardoor naar alle waarschijnlijkheid de gewonnen snelheid door de grotere block size teniet gedaan wordt. Maar dat is dan de prijs die je betaald om meer data op te kunnen slaan.

[Ronald]

ReiserFS met tailwriting optie aan.

Kan al Jaaaaaaaaaaaren.

[TheekAzzaBreek]

Maar dat kost je weer overhead die je nou juist niet wil. Terwijl de kosten van slack space enorm meevallen. In m'n windows directory met al z'n kleine bestandjes ligt het rond een percent, bij m'n mp3's al minder dan een promille. Niet de moeite waard.

[Verwijderd]

Ik neem aan dat ze de distributie van filesizes bekeken hebben, voor een paar verschillende systemen. Met wat geluk ook vergeleken met oudere varianten, om een trend te spotten.

Op die manier zoek je het optimum, tussen redelijke vulmogelijkheid (hele schijf 1 blok= evenveel schijven als files nodig) en snel vinden.

[Verwijderd]

Wat is het verschil met je bestandssysteem gewoon een grotere cluster/blockgrootte te laten gebruiken? Zelfs op NTFS kun je dit instellen?

[mOrPhie]

Dat is op FS niveau. Niet op hardware-niveau.

[it0]

Maar toch het aantal bits op de disk blijven hetzelfde ?

Dus het verschil is alleen adresseerbare ruimte (met grotere blokken kan je dus meer data adresseren) en dat kan het probleem toch ook niet zijn?

[RobLemmens]

De data wordt door de hardware in blokken gelezen, 8 blokken worden nu 1 grote. De schijf moet eerst zoeken naar het juiste spoor en dan naar het begin van het betreffende blokje om vervolgens de data in te lezen tot hij het stop teken tegenkomt. Door deze blokjes groter te maken kan de schijf meer data per leesactie pakken en zal er waarschijnlijk minder tijd verloren gaan doordat je nu maar 1 keer de start en stop tekens hoeft te checken in plaats van 8 keer.

[Ghost81]

Wellicht dat dit helpt. Dit is een stukje informatie van PC Wizard 2007 over een partitie van mijn harde schijf. Zie dat bij physical features staat "bytes per sector 512". Dat gaat dus veranderen. Daarmee veranderd dan ook de bytes per sector in the logical features.

Logical Features :
Sectors per Cluster : 8
Bytes per Sector : 512
Cluster size : 4 KB
Free Clusters : 6095626
Total Clusters : 34559823

Physical Features :
Cylinders : 30515
Heads : 255
Sectors per Track : 63
Bytes per Sector : 512

[tjerkw]

Een block in deze context is de kleinste hoeveelheid informatie dat een head kan inlezen/uitschrijven. Als deze groter wordt hoeven er dus minder lees actief uitgevoerd te worden. En wordt de schijf dus snel. Helaas heb je dan wel fragmentatie doordat je niet altijd elke block volkomen opvult.

De cluster waar jij het over hebt is inderdaad de NTFS cluster. De hiervan geeft aan hoeveel blocken er in een cluster zit. NTFS geeft bestanden weer dmv die clusters.

Als je een bestand ophaalt wordt eerst de meta-data van dat bestand opgehaalt. Daaruit kan vervolgens bepaald worden in welke clusters het bestand staat opgeslagen.

Als je grote clusters hebt voorkom je veel zoekwerk maar introduceer je ook halve-volle clusters. Ligt dus een beetje aan welke informatie je opslaat.

Je moet dus duidelijk onderscheid maken tussen
A) De hardware en de werking ervan (koppen cylinders blocks platters)
De implementatie van het filesysteem (FAT, NTFS, Reiser)
C) De software die de schijf aanroept

[Verwijderd]

Natuurlijk, clusters zijn softwarematig, en dit is hardwarematig. Maar in hoeverre is dat verschil relevant?

Als je filesystem standaard 4KB clusters gebruikt.... worden die 8 blocks op de harddisk dan niet vrijwel zeker sequentieel weggeschreven?

In hoeverre maakt deze hardware wijziging dan iets uit voor de snelheid? Maakt het uit of de harddisk 8 sequentiele 512 byte block uitleest, of dat hij één 4KB block uitleest? Harddisk hebben toch al read-ahead caching e.d., dus die 4KB leest hij op met 512byte block waarschijnlijk zowiezo al...

Ik heb zo'n gevoel dat we hier in de praktijk helemaal niets van zullen merken.

[gfgw]

Helaas heb je dan wel fragmentatie doordat je niet altijd elke block volkomen opvult.

Dat is geen fragmentatie, dat is slack. Fragmentatie betekent dat de blokken die samen de inhoud van een bestand vormen, niet achter elkaar staan.

[cybero]

NTFS slaat kleine files op in het MFT. Dat doet MS eigenlijk best slim. Dan heb je het probleem van kleine files die teveel ruimte innemen niet meer.

google.. hebbes

[Verwijderd]

Is FS niveau, niet HD/hardware... is parallelle evolutie, is niet hetzelfde.

[onetime]

het verschil is minder inter-sector gaps, waardoor er meer data op de zelfde schijf past, en omdat er meer data op de zelfde schijf staat, deze data dus ook sneller gelezen word, hij blijft even snel draaien...

hoeveel invloed dit heeft hangt natuurlijk af van de verhouding tussen de ruimte die de sectoren gebruiken en de ruimte die de inter-sector gaps nodig hebben.

ook word de maximale schijf grootte 8 (acht) keer zo groot, bij hezelfde adressering systeem, wat ertoe lijd dat disken tot 1TB weer met 28bit LBA kunnen worden geadresseerd (dit is ook iets efficienter), pas daarna hoeft er te worden overgestapt naar 48bit LBA.

(mischien word de cache ook wel efficienter als er minder blokken hoeven worden bijgehouden)

schijven zouden dit intern al toe kunnen passen, maar het nadeel zou zijn dat ze bij een schrijf actie een read-modify-write op hun grotere fysieke sector zouden moeten uitvoeren, als niet de hele cluster zou worden overschreven ... etc, maar ik dwaal af...

[Verwijderd]

De meeste bestandssystemen gebruiken nu al clusters van 4kB, dus dan ben je door je bestandssysteem sowieso 4KB per bestand kwijt, hoe het ook geregeld wordt op hardware-niveau. Dat lijkt me dus niet echt een nadeel (tenzij voor iemand die specifiek een clustergrootte van 512KB of kleiner instelt, maar die groep zal wel klein zijn)

[bavanandel]

512B bedoel je lijkt me.

Omgekeerd lijkt het met trouwens ook niet onmogelijk een bestandssysteem te ontwerpen dat kleine bestanden (dus van bijv. slechts enkele bytes) op een andere manier behandelt dan grotere, door ze bijv. "samen te voegen" op clusterniveau. Ofwel, meerdere kleine bestanden in één cluster zetten.

Allicht zijn er al bestandssystemen die zoiets voor de hand liggends al toepassen.

[Munters]

NTFS neemt voor kleine bestanden helemaal geen ruimte in beslag, de inhoud wordt gewoon in z'n geheel in de directory opgenomen.

[.oisyn]

Dan neemt het alsnog ruimte in beslag, alleen in de directory file, die alsnog een veelvoud van de clustersize is (meestal 4k). Dat is natuurlijk wel voordeliger, vooral als je veel kleine files in een directory hebt staan, maar de uitspraak dat het dan geen ruimte inneemt is natuurlijk onjuist

Overigens klopt je uitspraak sowieso niet, kleine files (alsmede kleine directories) staan volledig in de MFT zelf, zoals Mr. B al uitlegt.

[Mr. B.]

Allicht zijn er al bestandssystemen die zoiets voor de hand liggends al toepassen.

Inderdaad; NTFS slaat kleine bestanden op in de MFT (Master File Table).

[Fibbers]

Volgens mij is dat precies wat ReiserFS doet:
informatie-eenheden die minder dan een allocatie-eenheid (blocksize, zoals bijvoorbeeld 512 byte) omvatten, opslaan binnen 1 allocatie-eenheid, waardoor je met veel kleine files dus minder overhead krijgt.

[TetsuoShima]

Je bedoelt 512 byte denk ik.
(was te laat)

Maar idd, het ruimteverlies hierdoor is verwaarloosbaar omdat het filesystem dat door (ruwe schatting) 90% van de mensen gebruikt wordt de clustersize default op 4kB of hoger instelt (tenzij je met partities die kleiner dan 2GB zijn aan het werken bent en geen FAT (16) gebruikt.

De performancewinst zou er moeten zijn omdat het op dan op hardware niveau gerealiseerd wordt, ook minder fragmentatie dan.

Goeie zet, zou ik zo denken van die jongens.

[Andros]

Helaas hebben die blokjes ook een nadeel. Heb laatst een schijf van 500GB waar ik een half jaar op heb zitten schrijven, verwijderen etc eventjes gekopieerd naar een andere HD van 500GB. Had een verschil van 200MB. Puur omdat ie dan die blokjes beter verdeeld. En dat verschil gaat dus ook oplopen. Backupje en tussendoor formatteren wil nog wel eens ruimte vrijmaken...

[Munters]

Dit is niet mogelijk, de totale vrije ruimte moet gelijk zijn. Hooguit is de kopie wat sneller doordat er minder fragmentatie is.
Waarschijnlijk heb je wat verborgen bestanden niet mee gekopieerd. Of is er iets overgeslagen waar je op dat moment geen leesrechten op had. Of de pagefile speelt je parten. Genoeg verklaringen.

[BartS12]

En zelfs al klopt het..... 200 MB van de 500 GB is precies 0.04% .....

[Chatslet]

Volgens mij heeft hij gewoon nog nooit gedefragmenteerd.

[TheekAzzaBreek]

Fragmentatiegraad heeft geen invloed op de hoeveelheid vrije ruimte, hooguit op de snelheid.
Als werkelijk alle data zou zijn overgezet dan is het filesystem de oorzaak, niet de HD block grootte. Die is immers bij vrijwel alle schijven gelijk. Maar ik gok op Munters.

[Niemand_Anders]

Als je partitie een blocksize heeft van 4kb, dan neemt elke bestand een veelvoud van 4kb in beslag. Een tekstbestand van 1 letter neemt net zoveel ruimte in als een tekstbestand van 3500 tekens.

Dit komt omdat elk blokje maar aan 1 bestand kan worden toegekend. Daarom toont de explorer bij de properties ook twee soorten gebruik, namelijk werkelijke grootte van de bestanden en de grootte op de schrijf.

Het kopieren of verwijderen van bestand lost dit niet op. Defragmenteren zet alleen de blokken van een bestand bij elkaar zodat het OS alle blokken achter elkaar kan lezen en daarmee behaal je dus een performance winst.

Echter als je veel kleine bestanden hebt (bijvoorbeeld een grote 'temporary internet files' directory heeft, dan kan het gebruik op de hardeschrijf flink oplopen. Voor video/database/iso bestanden kun je beter weer grotere blokken gebruiken.

Als je ruimte overhoud, zou dat dat beteken dat je nieuwere schrijf kleinere blocks gebruikt dan je oude. De blokken zelf kunnen nooit een nadeel zijn. Want als het nadelig uitpakt heb je gewoon de verkeerde blokgrootte gekozen bij het formateren.

[TinusH777]

Om het simpel te houden: het verlies is gemiddeld 2kb per bestand.
Heb je 10000 files? Dat is je verlies 20000KB, dus 20MB

Overigens, je kunt de files op windows compressen: wanneer de files dan klein genoeg zijn, worden ze in de directory structuur zelf opgeslagen.

[maniak]

Laten we developers dan ook eens dwingen niet allemaal van die kleine bestanden te gebruiken maar wat meer samenvoegen. Dan houden we netto sneller transfers over met dezelfde kosten aan ruimte.

[spil]

Door de developer een algoritme te laten schrijven voor iets wat het filesystem al heel goed kan?

Het is niet ondenkbaar dat een developer een optimalisatie vind die voor zijn situatie sneller is, maar ik hoop dat moderne filesystems al zo ge-optimaliseerd zijn dat je niet veel meer gaat winnen.

Tenzij de developer natuurlijk het filesysteem omzeilt en een eigen partitie raw gaat benaderen (zoals bv. Oracle RDBMS dat kan)

[locke960]

Dat heeft Microsoft dus gedaan. Het heet "de registry".

Ik vind dat nog steeds Microsofts grootste technische fout ooit. Het systeem wordt er veel kwetsbaarder door. Maar goed, blijkbaar denkt de rest van de wereld daar anders over, de registry is er nog steeds.

[i-chat]

en in linux heet dat /etc - wat echt niet zo heeel erg raar verschild...

[Bloodshot]

Die vergelijking is een beetje kort door de bocht denk ik zo.
In /etc staan namelijk configuratiebestanden (.ini-files onder MS-windows gok ik zo). Als je daar iets in aanpast, wordt het niet per direct actief. (Daar is een stop/start van een service voor nodig). In het register is dit meen ik wel zo.

[oliveroms]

of de instelling per direct actief word is nog niet eens hetgeen waar het zo gevaarlijk van word.

/etc zijn allemaal losse individuele files en dirs. je kan een file deleten, je kan een file editen, de andere blijven nog goed.

delete maar is je system.dat, heb je de poppen aan het dansen hoor.

Centralizeren kan handig, voordelig en efficient zijn, maar een registry, dat ook nog is makkelijk vervuild, was een ontzettende groote technische fout.

[Verwijderd]

Ik denk dat jou reactie een beetje kort door de bocht is want je weet duidelijk niet waarover je het hebt.

Er zijn op zowel op linux (in /etc) als op windows (in de registry) zaken die kunt aanpassen die direct actief zijn als dat er zaken zijn waarvoor een restart nodig is van een service.

Ik snap echt totaal niet hoe je bij die beredenering komt, ben wel erg benieuwd hoe je eraan komt.

[Molybdenum]

gewoon met een jumpertje in te stellen door de gebruiker, kan je mooi zelf kiezen. zou dat niet handig zijn?

[FlorisB]

Maar dan moet je telkens een low level format doen? Want met die blocks wil je echt niet gaan spelen hoor.

[Laurens-R]

Je bent toch een tweaker of niet dan?

Ik heb genoeg lowlevel formats uitgevoerd. Nadeel van veel lowlevel format software is dat het nou niet echt idiot proof is. Als ze nou een geschikte utility voor de gemiddelde 'huis tuin en keuken' gebruiker zouden maken...

Ik kan me nog een tijd herinneren dat low level formatting standaard in de BIOS gebakken zat. Heeft me heel vaak geholpen met het redden van HD's

[burne]

Je bent nu 24 dus net aan oud genoeg om nog een werkende niet-IDE pc gezien te hebben. Van de andere kant waren toen jij tien was PC's met een ST406 of ST512 al behoorlijk zeldzaam. En 'low level formats' op IDE-drives is in nagegenoeg alle gevallen onzin. Je kunt zelf geen embedded servo schrijven, dus alles wat de drive voor je doet is de sector met nullen vullen. Maar dat is geen low-level format. Dat zit er alleen maar in voor de compabiliteit.

[Laurens-R]

Nee, je hebt het fout...


Ik ben 23


Daarbij hadden wij in de tijd (toen ik idd 12 ofzo was) een 486 die ook lowlevel kon formatten hoor... zolang zijn die machines ook weer niet uit de running (ongeacht van het feit of het wel of niet een 'echte' lowlevel format was)

[Verwijderd]

ik denkd at meer flexibiliteit ten koste gaat van de performance, en daar is het nu juist om te doen...

[Verwijderd]

Oke, long Blocks dus. Zit ik dan in de goede richting als ik zeg dat long blocks door hun grote als er een block kapot gaat meer ruimte ongeschikt word om te gebruiken?

Als er een krasje komt wat een 512 bl;okje ongeschikt maakt is dat maar 1 blokje van 512 en een krasje van dezelfde grote doet dan meteen 4096 schade.

[Cameleon73]

Da's waar, maar als je dan een snelheid <-> krasbestendigheids overweging doet, komt je snel uit op een groter voordeel voor de 4K blokken. Je leest en schrijft nu eenmaal veel vaker dan dat er een beschadiging op je HDD komt...

[Theadalus]

In principe heb je wel gelijk, maar je hebt het hier wel over bytes, niet erg interessant wanneer je een 100+GB HDD hebt.
Overigens heb ik zelf de vuistregel dat wanneer een HDD fysieke beschadigingen (blokjes) begint te vertonen, deze zo snel mogelijk vervangen wordt. Want... een beschadigd blokje komt nooit alleen!

[REDFISH]

Ik dacht, laat ik eens kijken hoeveel bestanden op mijn c schijf staan kleiner dan 4kb. Na 1 minuutje zoeken een waslijst aan bestanden.

Ik kies Ctrl+A en daarna deed zoekresultaten niks meer anders dan Explorer op 100% cpu gebruik te zetten en niks meer te produceren.

De berekening met de verloren schijfruimte waar ik iedereen op had willen trakteren zit er dus niet in.

[DrBOB101]

Aangezien je elk bestand in stukjes van 4096 bytes moet verdelen is de kans 1 op 4096 dat een bestand precies in een x-aantal vakjes past.
Gemiddeld genomen (voor "willekeurige data") zal een bestand 2047,5 bytes te groot zijn.
Stel je hebt 40.000 bestanden dan verlies je dus 2047,5 * 40.000 = 81.900.000 (ook wel 78,1 MB)
Even ter vergelijk met clusters van 512 bytes is het 9,7 MB.

[onetime]

vroeger, bij de eerste "consumer" hd's kon je dat met de low-level format toch zelf instellen? (5, 10, 20, 40, 80 MB...)
zo kon je mfm disks ook RLL formatteren, foila, geen 20 maar 30 MB (als het werkte, niet alle disks waren goed genoeg...)

[sKweezr]

OK, windows Vista ondersteunt het al.
What about Windows XP?