Western Digital stapt over op 4kB-sectoren bij Caviar Green-hdd's

Fabrikant Western Digital heeft een nieuwe indeling voor de datablokken van zijn Caviar Green-harde schijven geïntroduceerd. De datablokken zijn vergroot van 512 bytes naar 4 kilobyte, wat de hoeveelheid overhead moet verminderen.

Sinds jaar en dag zijn de logische datablokken van harde schijven onderverdeeld in sectoren van 512 bytes, maar naarmate de capaciteit van harde schijven toeneemt, zorgt dit voor veel onnodig ruimteverlies. Elk blok wordt namelijk geflankeerd door blokken gegevens die het juist wegschrijven van data moeten faciliteren. Hierbij is vooral het blok dat voor ecc of foutcorrectie gereserveerd wordt inefficiënt. Western Digital ontwikkelde daarom een moderner indeling voor de data op informatiedragers en noemt deze architectuur Advanced Format.

Volgens WD zou vooral het reduceren van het aantal ecc-blokken een forse capaciteitswinst tot gevolg hebben: het weglaten van een groot deel van de sync/dam-blokken - de lege ruimtes tussen sectoren en de ecc-blokken - zou de bruikbare capaciteit van een harde schijf met 7 tot 11 procent kunnen vergroten. Om compatibiliteit met oudere apparatuur te waarborgen emuleert de Advanced Format-firmware de nu nog gebruikelijke 512 byte grote blokken. Windows 7 en Vista kunnen out-of-the-box al met de 4kB-blokken overweg; voor Windows XP heeft Western Digital een tooltje beschikbaar gesteld die dit OS daar alsnog geschikt voor maakt.

Nieuwe harde schijven uit de Caviar Green-serie zijn de eerste drives met de Advanced Format-technologie aan boord. De platters moeten bij het fabricageproces geschikt worden gemaakt voor het gebruik van de 4kB-sectoren; het is niet mogelijk om reeds geleverde schijven met een firmware-upgrade alsnog van de nieuwe indeling te voorzien. De eerste 500GB-per-platter-drives met AF, in capaciteiten van 1TB, 1,5TB of 2TB, worden inmiddels geleverd; ze zijn herkenbaar aan het typenummer EARS op het eind en de 64MB in plaats van 32MB grote cache. WD verwacht dat het Advanced Format binnen vijf jaar door alle harddiskfabrikanten wordt gebruikt.

Reacties (151)

[onetime]

http://tweakers.net/react...=Posting&ParentID=2008431

eindelijk een implementatie, zie mijn reactie hierboven van mei 2007...

[totaalgeenhard]

Eigenlijk niet zo gek, aangezien er steeds meer RAD "programmeurs" inefficiënt met geheugen om gaan, waardoor je amper meer files hebt die minder dan 4KB groot zijn.

Sla maar eens een lege notepad document op (met 1 karakter).

Jammer dat er geen lobby of andere op hef is over het feit dat programmeurs steeds luier en slechter programmeren. In de derde wereld landen beginnen ze op oudere/langzamere hardware waardoor ze ook op lagere niveau (c en assembler) leren programmeren, met duizenden tegelijkertijd, terwijl er in b.v. in Nederland amper een opleiding in reguliere onderwijs te vinden is waar je deze talen nog leert. (of leerde)

[.oisyn]

Eigenlijk niet zo gek, aangezien er steeds meer RAD "programmeurs" inefficiënt met geheugen om gaan, waardoor je amper meer files hebt die minder dan 4KB groot zijn.

Anders ga je eerst even gedegen onderzoek doen voor je een willekeurige groep mensen ergens de schuld van geeft. Feitelijk bega je nu exact dezelfde fout als waar je die lui van beschuldigt, namelijk niet rekening houden met alles in het systeem.

De inefficienctie van files hebben compleet niets te maken met de sectorgrootte van de HDD, en alles met de indeling van het filesysteem. Het is ranzig inefficient (zowel kwa snelheid als kwa hoeveelheid gebruikte schijfruimte!) om iedere individuele byte van een partitie alloceerbaar te maken, en daarom gebeurt dat doorgaans in blokken van typisch 4kB (wat tevens ook de page-grootte is van de CPU). Het resultaat is dan idd dat een file van 4097 bytes op een dergelijk filesystem dan idd 8kB in beslag neemt. Dit lijkt in eerste instantie weggegooide ruimte, maar daar krijg je wel een veel sneller systeem voor terug.

[Reactie gewijzigd door .oisyn op 23 juli 2024 06:48]

[Madrox]

Precies. En dan nog zijn de prestaties met kleine benstanden niet geweldig; daar heeft je harddisk geel veel moeite mee. Jammer dat daar niks op te verzinnen is.

Als de bestanden nog kleiner zouden zijn, ik zou er niet aan moeten denken wat dat doet voor de prestaties van de harddisk

[MaZeS]

Omgaan met geheugen en de grootte van bestanden hebben meestal niet al te veel met elkaar te maken... Als helemaal niet met de minimum grootte van een notepad document..
Aangezien RAM(ik neem aan dat je dat bedoelt) geheugen daarnaast een van de snelste te benaderen bewaarplaatsen voor informatie is is het daarnaast soms verstandig om er WEL zoveel mogelijk gebruik van te maken..
En waarom assembler en c tegenwoordig steeds minder worden gebruikt? Omdat het veel langer duurt om iets te bouwen, en je dan ook nog eens een grote kans op geheugenlekken/bufferoverflows etc hebt.

[Reactie gewijzigd door MaZeS op 23 juli 2024 06:48]

[totaalgeenhard]

De reden dat cluster grote is gegroeid komt door de verandering van gebruik en gemiddeld bestand grote. In dat optiek is het gewoon logisch dat fysieke cluster grote overeenkomt met dat van meeste filesystems. Dat het sneller is door o.a. grote blokken te kunnen lezen als ook minder ECC controles (een kwart minder).

Aan de andere kant bij data recovery ben je MEER data kwijt.

Dat "hogere" talen minder capabele programmeurs instaat stelt iets gericht op functionaliteit te maken, is mooi. Echter dat er minder fouten gemaakt kan worden is niet per definitie zo. Immers een "hello world" standalone compilen kost in de meeste talen tegenwoordige vele megabytes, waaraan die programmeur niet gezeten als ook niet heeft (of kan) controleren. Memoryleaks ontstaan om vele redenen, die niet allemaal afgedekt kunnen worden (heb al een tijdje last van firefox onder win7 64bits). Iemand riep garbage collectie, deze zullen nooit efficiënter kunnen werken dan indien een programmeur zijn eigen troep zelf kan opruimen. Ik denk dat juist doordat mensen rekening houden met garbage collector ze inefficiënt met geheugen om gaan.

Ben overigens geen top programmeur en al jaren geen projecten gemaakt. Maar ik vind het wel vreemd dat we meer resources accepteren als compensatie van inefficiëntie programmeurs.

Windows 3.1 kon al alles wat ik er mee zou willen, echter op hedendaagse hardware zou het qua snelheid en resources ten dienste staan van mij en niet zoals vandaag de dag dat je Quadcore CPU + 8 GB DDR3 + 1 TB (raid 1+0) hebt en je bij een paar vensters of als je virusscanner start je systeem jouw laat wachten.

Met andere woorden, qua hardware is het misschien wel veel beter en betaalbaarder geworden maar door die RAD en diens gebruikers zorgen er wel voor dat je er minder uit zult halen. (plezier aan hebt)


*** off topic ***

Had niet het idee dat ik een knuppel in een hoenderhok gooide, ben inderdaad een dinosaurus die als laatste een X windows ging gebruiken. En heb vele demoscene parties bezocht. En weet wat er met 64KB al mogelijk is. -met hedendaagse hardware... zou ik weleens willen zien-

*** /offtopic ***

[Verwijderd]

Als je gewoon met een script werkt of met dynamische bibliotheken (hergebruik) dan loop je niet tegen die problemen aan van kostbare opslag.

Een script kan makkelijk uit een honderdtal bytes bestaan.

Maar ik ben het helemaal met je eens als je naar bepaalde applicaties kijkt die honderden megabytes in beslag nemen terwijl het misschien ook wel in 25 mb of minder zou kunnen.

Het is belangrijk dat je de juiste instellingen voor de compiler kiest (stack groote, initial heapsize, libraries ).

Als je naar de effectieve code in een applicatie gaat kijken kom je inderdaad vaak op hooguit een paar duizend regels uit. Dat is ruwweg 100kb, en dat is het nog niet eens gecompileerd.

Kant en klare objecten maken programmeren flexibeler en sneller maar kosten veel resources, en dat is inderdaad zonde. Vooral als de gebruikersgroep groot is zou men daar meer aandacht aan kunnen besteden.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:48]

[Verwijderd]

Is het ook niet zo dat die kant en klare objecten ook heel veel functies bevatten om 'iedereen' te pleasen? En niet een enkele specifieke functie bevattten? Om iedereen dus te pleasen en niet te vervelen met duizenden downloadables om daar weer een samengesteld object of wat dan ook van te maken, heb je tegenwoordig die resourcevretende packs. Ben het met je eens dat gebruikersgroepen daar echt op moeten gaan letten. Het is de Westerse wereld op de digitale wereld geprojecteerd qua verbruik

[Verwijderd]

Ja, daar ben ik het helemaal mee eens. Al die functionaliteit / flexibiliteit is dus van harte welkom van de ene kant. Maar het creeeren van sub classes en toevoegen van functionaliteit die stroom afwaarts misschien helemaal niet nodig is kost echter veel resources. Er bestaat simpel weg geen eenvoudige manieren om classes 'lichter' te maken. Daarvoor moet je de parent classes gaan aanpassen. En dan ga je steeds dieper graven. In dat geval is het dus beter om een (bijna) geheel nieuwe class te creeeren.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:48]

[Verwijderd]

Moderne garbage collectors zijn enorm goed geworden in het opruimen van inefficient geallocceerd geheugen, dus je bewering houdt weinig steek.
Voor wat meer uitleg paste ik hier een informatief linkje van een interview met James Gosling waarbij het heeft over de garbage collector:

http://parleys.com/displa...ing%20at%20JavaPolis%2707

[Verwijderd]

Lang leve de HEEEL efficiente garbage collectors. Ik heb eens een eenvoudige proef gedaan op het werk. Een eenvoudige proef applicatie met een eenvoudig 'spreadsheet' datamodel. Dus 4 classes een root, kolom, rjj en cell, de rij had een klein array met wat willekeurige data. vervolgens een spreadsheet van 1000x1000 geinstantieerd. En als test om de 10 rijjen 1 rij weggooien en aan het eind weer niewe rijen maken totdat originele groote er weer was. Vervolgens hetzelfde met de kolomen. Dit vervolgens in een loop 100.000 keer doen. Dit alles was in 15 min in elkaar geclicked met een freeware code generator tool 'ClassBuilder', deze had een run time van ongeveer 40 seconden. Een collega die de uitdaging aannam maakte een equivalente oplossings maar deed de implementatie met de STL librarie, die had 400 seconden nodig, dus al 10x langzamer. Vervolgens mocht een grote C# adapth aan de gang, helaas voor hem is de applicate na enige uren draaien maar afgebroken. De geweldige gargabe collector was helemaal niet zo geweldig.
Lees nog maar eens heel goed, als swtukken geheugen tweede orde worden, dan wordt het heel erg duur om ze te collecten, tevens als het in core geheugen gebruik hoog is, dan is de compactie van het geheugen ook geen pretige bezigheid. Dus er zitten wel degelijk wel wat haken en ogen aan het garbage collecting. Voor veel toepassingen kom je ermee weg, maar er zijn situaties dat het heel pijnlijk kan worden.
Voor de liefhebbers stuur ik met alle liefde de C++ code op, dan kunnen ze zelf java, C# of andere derivaten maken en zelf kijken wat er gebeurt.

[Verwijderd]

Zelfs recente JVMs van Sun ruimen geheugen nog niet helemaal goed op en veroorzaken met bepaalde best normale constructies out of memory issues waar hiervoor helemaal geen noodzaak voor is. En dat is na meer dan 15 jaar werk eraan. En er is al die tijd altijd een betere bijna klaar die het probleem zal oplossen...het komt er alleen nooit van. Het is volgens mij ook meer een geloof in GC en een gebrek aan basale programmeer kennis die GC zo populair maakt onder nieuwe programmeurs.

Wat betreft demo programma's....als je goed kan programmeren is het doorgaans functioneel goed mogelijk in C++ een veel beter presterend resultaat neer te zetten dan met een op een GC gebaseerde taal. Je moet dan natuurlijk wel zelf over geheugen opbouw na gaan denken en hoe je interactie ermee is....die vrijheid heb je en daarmee komt ook meer verantwoordelijkheid. En ja, dat kost zeker meer programmeer werk en tijd. Je wordt dan wel beloond met een kleinere en meer statische (beter voor je processor) geheugen footprint en minder overhead waardoor je geavanceerdere constructies kan implementeren met betere prestaties als gevolg.

Zo moet je geheugen allocaties met eenzelfde lifetime als een groot blok (of serie daarvan) met meerdere elementen tegelijk alloceren (niet te verwarren met "contructen"). Als je verwacht 500 elementen van objecttype A nodig te hebben voor een bepaalde operatie, dan doe je 1 geheugen allocatie met ruimte voor 500 elementen en doe je individuele dynamische new operaties als nodig met behulp van een placement new. Vrijgeven van geheugen kun je dan voor alle 500 elementen in 1 keer doen. Eventuele destructors die als je het goed doet inline zijn worden gewoon optimaal verwerkt zonder overhead of zelfs weg geoptimaliseerd door de compiler als ze leeg zijn.

Daar kan geen GC tegenop. Je moet dit met template classes invullen natuurlijk, je gaat dit niet voor iedere class opnieuw programmeren. En natuurlijk zijn er altijd scenario's te verzinnen waar een GC (automatische runtime afhandeling) beter werkt, net zoals iedere benchmark naar je hand gezet kan worden. Maar claims dat een GC * per definitie * beter werkt en we niet meer om moeten kijken zijn onzin. Het werkt voor de meesten echt gemakkelijker, maar het is niet zonder nadelen...niets is geheel gratis in het leven en je kan in iedere taal troep schrijven. Vergeet dit laatste nooit in dit soort vergelijkingen.

Wat betreft geheugen lekken in C++, met een bepaalde programmeer stijl zijn lekken vrijwel uitgesloten aangezien de compiler voor alle mogelijke exits de passende opruim code automatisch voor je aanroept. Als iedere classe zichzelf netjes op kan ruimen is het voldoende met behulp van de stack unwinding de levensduur van objecten van die klasse te scopen en de compiler doet de rest. Dit kan ook voor objecten die op een heap zijn gealloceerd, moet je alleen een smartpointer of met een template gemaakte opruim classe voor het specifieke object op je stack zetten die wanneer het out of scope gaat automatisch destruct en ook het gealloceerde heap object meeneemt.

Uiteraard moet je geen circulaire referenties maken of alles met referenties aan elkaar pointeren zoals beginners vaak doen omdat er geen helder design is. Je moet dus weten waar je mee bezig bent en kunnen programmeren. Dezelfde constructies zijn voor een GC ook een ramp bij het opruimen van geheugen, maar zoals de eerdere poster al schreef...je komt er heel vaak mee weg en dat maakt het gemakkelijk.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:48]

[jDuke]

Basis van een GC is gewoon als de verwijzing van de stack naar de heap weg is dat ie dan wordt opgeruimd. Dus als je dan wat rijen gaat verwijderen en je gooit de parent class weg (alle verwijzingen van de subclasses verdwijnen dan ook) is het object gelijk aangemerkt voor GC. "Probleem" van Java etc dat geheugen beperkt wordt. C++ gaat eigenlijk onbeperkt verder. Ik durf de uitdaging zeker wel aan met Java. Ik heb C++ gedaan (niet heel veel). Op mijn Java examens wordt ook veel aandacht besteeds aan GC.

De huidige GC algoritmes zijn zeer uitgebreid en efficient, zolang je alles goed afconfigureerd (genoeg geheugen als je plotseling erg veel gaat doen). Tevens in deze zeer geheugen intensieve programma's kun je beter GC hebben vanwege geheugen lekken etc, die krijg je redelijk snel in grote applicaties waar veel data heen e nweer gepompt wordt.

[Verwijderd]

Ik ben benieuwd hoe goed dat nu in de praktijk allemaal werkt bij COM objecten en interfaces waarbij de programmeur vaak zelf aan moet geven dat de reference counter van een instance verlaagd moet worden. Ervaring met geheugen leaks en het debuggen ervan m.b.t. COM ? Ik neem aan dat GC niet altijd goed zal werken.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:48]

[Xenan]

COM objecten worden geschreven in C/C++. Dus niet in managed code zoals C# of Java. Er is hier dus geen sprake van GC.

[Verwijderd]

Ik heb begrepen dat com objecten ook in andere talen geschreven kunnen zijn (niet alle) zolang aan bepaalde regels voldaan wordt. Dat van die GC is me nu duidelijk. Maar mijn volgende vraag is dan eigenlijk: Hoe gemakkelijk is het over het algemeen om memory leak te voorkomen als je applicaties schrijft die COM gebruiken. Het lijkt me dat het met die reference counters snel onoverzichtelijk wordt.

[Verwijderd]

Je hebt gelijk dat er ook andere talen zijn waarin COM objecten geprogrammeerd kunnen worden. De meest gemakkelijke is wel het oude bekende "Visual Basic 6".

Wanneer je in VB6 COM objecten maakt en/of gebruikt heb je helemaal niets met reference counters te maken, dat wordt onder water voor je geregeld door de VB compiler. In deze omgeving gaat het dan ook eerder fout door circulaire referenties, waardoor een reference counter nooit op 0 kan komen. Met als gevolg dat het object en ALLE van daaruit gerefereerde objecten niet worden opgeruimd...de wel bekende memory leaks. Je moet eerst alle referenties zien te breken en dat betekend dat het dus niet altijd automatisch voor je gebeurd by een slecht uitgewerkt object model.

Vanuit C++, waar ik overigens nog zelden in ontwikkel (helaas), gebruikte ik nooit COM objecten. Dus hoe het daar met reference mamagement zit dat weet ik niet uit ervaring. Ik denk dat het normaal is dat er een wrapper class omheen te zetten die het voor je afvangt.

Wanneer de wrapper class instance (smartpointer) deleted wordt, dan zal de destructor de COM referentie met 1 verlagen en wordt het object opgeruimd als de teller op 0 komt. Niet zo heel ingewikkeld, maar wel net iets meer werk dan met bijvoorbeeld VB6. Het is denk ik een kwestie van een juiste techniek aanleren.

Verder heb je nog threading.locking issues als je met C++ werkt, iets waar VB6 met een COM object volgens het appartment threaded model geen extra werk vergt. Zij het dat je dan maar 1 thread tegelijk gebruik kan laten maken van het object. In C++ kun je dus COM objecten maken die wel threaded werken met alle extra complexiteit van dien.

[immetjes]

Mijn notepad bestand is 1KB. Dat is toch minder dan 4KB?

[johnkeates]

Denk je dat 1 karakter 1KB nodig heeft?

[MaZeS]

Wel als je clustergrootte van de partitie is ingesteld op 1kb...
De reden waarom dit wordt gedaan is dat de blokken van een bestand moeten worden bijgehouden in een "tabel": .. De blokken van een bestand staan namelijk niet altijd achter elkaar.
Zie het volgende voorbeeld bij een bestand van 4 bytes:

Als ieder byte apart zou worden opgeslagen in de tabel had je 10 bytes nodig:
-byte 1 staat op plek 3012312
-byte 2 staat op plek 3324233
-byte 3 staat op plek 232132
-byte 4 staat op plek 967678
Je bent dan dus 10 bytes plus de 4 bytes in de tabel kwijt = 14 bytes

Als je met een blok van 1024 bytes werkt is er maar 1 byte in de tabel nodig:
-De eerste byte van de 1024 begint op plek 2048
Je bent dan 1025 bytes kwijt.


De voorbeeld hierboven zijn slechts te illustratie, en ieder byte bijhouden zou het efficïents zijn..
Vanaf 513 bytes is het echter anders.. Dan wordt het bijhouden van blokken van 1024 bytes efficïenter. Een blok van 513 bytes zou namelijk 1024+1 byte = 1025 bytes kosten.
By ieder byte apart zou dit 513+513=1026 bytes kosten....

De meest efficïent blokgrootte is dus afhankelijk van de gemiddelde bestandgrootte

@ArnoutV:
Een notepad file van 1 byte neemt wel degelijk 1kb in op de schijf.. Dat betekent alleen niet dat het bestand ook 1kb aan inhoud bevat... Het heeft in ieder geval niets met afronding naar boven te maken.

[Reactie gewijzigd door MaZeS op 22 juli 2024 14:26]

[Verwijderd]

Aan 1 byte per blok extra heb je niet genoeg voor hert bijhouden een byte kan namelijk slechts waardes van 0 t/m 255 opslaan. Hedendaagse filesystemen zijn 32, 64 of zelfs 128 bits. En gebruiken dus 4, 8 of 16 bytes voor dit doel plus nog wat extra voor efficiente zoek bomen zoals B* bomen.

Aan de andere kant zijn een hoop systemen tegen woordig ook in staat om de laatste stukjes van bestanden te groeperen in een enkel blok. Reiserfs kan dit bijvoorbeeld al wordt het er niet sneller van (tail/notail optie). Tevens zijn er filesystemen die heel kleine bestanden direct opslaan in de directory entry waar ook de naam en normaal de verwijzingen staan.

[Wim-Bart]

Tevens zijn er filesystemen die heel kleine bestanden direct opslaan in de directory entry waar ook de naam en normaal de verwijzingen staan.

NTFS dus, bestanden tot 48 bytes groot

[ArnoutV]

Een notepad file met 1 character is ook niet 1KB groot.
Dat is wat de verkenner toont, nl afgerond op KB, en ja het is naar boven afgerond

Een bestand in Notepad met alleen de letter a, zonder return is precies 1 byte groot.

[Verwijderd]

jij moet toch maar eens goed nadenken over de werking van computers en disken... denk je dat je disk een lijst heeft van alle bytes? Dan zou je weinig overhouden. Daarom de indeling in clusters

[Nico Klus]

De verkenner rondt inderdaad wat af. Als je het precies wilt weten moet je de properties opvragen en dan zie je keurig:
Size: 1 bytes (1 bytes)
Size on disk: 4.00KB (4,096 bytes)

[doctormetal]

Ja maar hij neemt wel een volledig blok in beslag.Dit zal bij de defautt instelling van ntfs dus 4kB zijn.

[Wim-Bart]

Onder NTFS niet, daar zit ie gewoon in de directory entry. Bestanden tot en met 48 bytes krijgen onder NTFS geen separate cluster.

[Verwijderd]

Nee, dat is de afgeronde aantal bytes. Maar dan niet eens het aantal bytes op de schijf zelf. Op Windows XP(64 bit) zie ik bij een textfile 1 byte staan, en 4.096 bytes van de harddisk in beslag nemen.

Maar ik snap even het punt niet van totaalgeenhard: Trekt hij nu een voorbeeld uit Notepad naar aanleiding van z'n eerste alinea? Dan valt er niets op te merken, behalve dat het bestand fysiek 4kb inneemt ipv de logische 1 byte met die textfile met 1 karakter. Dat moet je los zien van inefficiënt met geheugen omgaan, en dat programmeurs daar debet aan zijn in het geval van Notepad iig. Maar het is wel efficient omgaan met de technische mogelijkheden van de moderne schijf.

[fdm391]

Ga een willekeurige (Technische) Informatica studie of Elektrotechniek volgen en je leert het wel hoor, assembly en C.
Er is alleen gewoon veel vraag naar programmeurs voor hogere level talen, zoals C#, Java en de rest. Simpelweg omdat het programmeren makkelijk en snel gaat. Ook de goedkope x86 hardware helpt hier natuurlijk bij. Iedereen heeft tegenwoordig wel een of meerdere PC's.

Ga jij maar eens een windows applicatie in assembler schrijven, ik wens je succes.

Wat ik wel met je eens ben is dat veel programmeurs in hoge talen als C# bijv. geen flauw benul hebben hoe het geheugen van een PC gemanaged wordt of inderdaad ook hoe de opslag van data gebeurt. Ze zouden dit mijns inziens wel (ongeveer) moeten weten, ook al gebruiken ze de kennis in de praktijk nooit direct.

[Kevinp]

Dat is de rede dat wij wat assembler en C hebben gekregen op school. Nou ja C ook voor de embedded zooi. Om inzicht te krijgen wat een processor en geheugen precies doen, en dat dan ongeveer te onthouden.

[Verwijderd]

Een programmeur hoeft die zaken helemaal niet weten, das voor het CLR ontwikkelteam. Zij moeten vervolgens wel uitleggen aan de programmeur wat het beste is en daarvoor hebben we common practices.
Leuk als je gepassioneerd bent door je werk maar ik kan gerust zeggen dat minstens 50% van de programmeurs buiten het werk hun pc voor niet meer gebruikt dan mailtjes lezen of naar porno surfen. Ik zie elke dag mensen die niet verder kijken dan de lettertjes in hun cursus.

[jDuke]

Gelukkig is er ook meer op deze wereld dan .NET (CLR). Er zijn ook genoeg talen waar geen VM nodig is dat de compiler het naar native code compiled (C++ etc). Ik heb ook Elektrotechniek gedaan en daar leer je veel programmeren voor embedded apparatuur, daar leer je wel degelijk efficient programeren. Ik doe nu Java, maar dat neemt niet weg dat ik niet efficient programmeer. Ik vind dat je hoe dan ook zo efficient moet programmeren, ongeacht hoe makkelijk een taal moet zijn.

[NLxAROSA]

Of je nu voor een virtuele of echte machine ontwikkelt, het heeft altijd nut om kennis te hebben van hoe de compiler/machine omgaat met opslag en datatypes. Ook een virtuele machine slaat immers dingen op. Dat is standaard kennis dat je er bij een Programmer certificaat (in ieder geval bij Sun) ingeramd krijgt. Zal bij Microsoft niet anders zijn vermoed ik???

[Reactie gewijzigd door NLxAROSA op 23 juli 2024 06:48]

[MisterBlue]

Een programmeur hoeft die zaken helemaal niet weten, das voor het CLR ontwikkelteam. Zij moeten vervolgens wel uitleggen aan de programmeur wat het beste is en daarvoor hebben we common practices.

Maar je zult altijd wel leaky abstractions hebben, waardoor het wel handig is om wat meer te weten van de laag eronder.

[Verwijderd]

Dat is een interessant artikel en het is ook meteen de reden waarom ik vaak c++ builder objecten mix met win32api aanroepen. Vaak is de documentatie van voorgebakken objecten ook dusdanig beperkt dat het sneller gaat zelf de benodigde functionaliteit te produceren, met soms ook meer betrouwbaarheid en overzicht (dat is ironisch). Deze mix werkt vaak ook efficienter.

[Vaudtje]

*Hap*
Het is gebleken dat deze 'RAD is poep' software over het algemeen een stuk onderhoudbaarder is dan het obscure byte-shifting assembly obfuscated hyperperforming GOTO spul. Verder doet software tegenwoordig wel wat meer dan de console apps van de jaren zestig.
De opoffering die daarvoor wordt gebracht is inderdaad het resource gebruik, maar zoals WD hier weer laat zien, kan dit met hardwareverbeteringen opgevangen worden.
Denk er aan dat de waarde van software zit in het nut dat de gebruiker ervan heeft, niet in de trots waarmee de programmeur het op zijn CV zet

[johnkeates]

Dat hangt van je doelgroep af, en in het grote plaatje totaal onbelangrijk wat je daar zegt.

Dat JIJ voor GUI kiest maakt niet dat de wereld jouw keuze volgt.

[Soldaatje]

Je hebt gelijk, de meeste mensen gebruiken helemaal geen GUI, veel te onhandig en kost te veel resources.

Maar ja, misschien dat volgend jaar met Windows 3.1 daar verandering in komt.

[BlackOwl]

Altijd grappig hoe die paar dinosaurussen die nog bij de command line zweren menen te moeten doen alsof ze een meerderheid vormen.

[Verwijderd]

Om nou te doen alsof alleen dinosaurussen de command line gebruikenen is ook een beetje apart.
Er zijn genoeg situaties waar je met de command line sneller bent, probeer maar eens ff alle .torrent bestanden van je harde schijf te verwijderen bijvoorbeeld.
Of om even 2 pdfjes te combineren.
Of even snel te kijken of je uberhaupt wel een internetverbinding hebt. (ping)

[mtak]

Nooit geweten dat een paar dinosaurussen 7,4 miljard waard zijn (overname van Sun door Oracle).

Btw, ik zie niet echt wat RAD met GUI's te maken heeft (ik ken ook genoeg command line unix tools die niet vooruit te bakken zijn door RAD).

[Verwijderd]

Oracle, ook weer zo'n mooi voorbeeld van bloatware. Er zijn modernere database pakketten, die sneller en veel kleiner zijn. Het oude Oracle 8 installeert al 100.000 bestanden op je schijf. Geen wonder dat openen van een bestand dan langer duurt. Je FAT wordt er zeer inefficient en overvol van. (Liever op een aparte partitie zetten dus.)

[mtak]

Veel succes met het draaien van een 7TB database op je standaard Debian MySQL Oracle valt niet voor niks in de Enterprise markt (net zoals bijvoorbeeld Sybase en Informix, wat net zulke bakbeesten zijn).

[Verwijderd]

Databases die wederom op functionaliteit gebaseerd zijn, en niet op snelheid Maar de enterprise markt rouwt daar over het algemeen ook niet om. Het wil gewoon veel.

[Verwijderd]

Typisch kapitalistisch "pragmatiek boven alles" RAD poep mentaliteit ja.

Pragmatiek en functionaliteit is inderdaad een meer primaire behoefte dan esthetiek, en natuurkundige efficiency, in tegenstelling tot een kapitalistische definitie daarvan waarbij inefficiency wordt goedgepraat door vergroten en versnellen van finitiete exploitatie.

Bedenk wel dat zonder die RAD poep je PC hardware 2x sneller had kunnen werken. De ketting is zo sterk als zijn zwakste schakel, en dat moet je dus niet hebben in de lagere lagen van je abstractie model want de effecten spelen door op alles wat ermee is gebouwd of ermee samenhangt.

Met name vandaag de dag moet je je ook nog eens extra bewust zijn van natuurkundige energieverspilling, levensduur van batterijen, etc. Dus het is ook nog eens crimineel onverantwoord om RAD poep te ontwikkelen. De enige die RAD poep rechtvaardigt is de kapitalitische mentaliteit die zowieso weinig met ethiek van doen heeft.

Dat betekent niet per definitie dat alles in assembler moet, maar de verhoudingen tussen assembler en C (voor en nadelen) liggen echt wel anders dan tussen C en .NET poep. En dan weegt het een niet op tegen het andere.

Bovendien heb ik meer vertrouwen in iemand die .NET ontwikkelt maar met sterke C/C++ achtergrond dan iemand met VB achtergrond voor wie hoe alles onder de motorkap werkt nog magie is. Met RAD kom je te makkelijk weg met gebrekkige inzichten en kennis en het bedrijfsleven kan dat niet beoordelen omdat zij enkel functioneel en financieel denken.

Software zou ook energielabels moeten hebben.. Dan krijgen meeste RAD apps een F per definitie en zal een A veelal C zijn en A+ assembler optimized, en A++ volledig assembler, wat voor veel firmware ook beste keus zal zijn.

En software met slechtere energieverbruik moet extra belast worden.. dan geven we er meteen ook een kapitalitische betekenis aan.

[YGDRASSIL]

Dat energielabel moet dan ook bevatten hoeveel er verstookt is/wordt tijdens het maken en onderhouden van de software. Dat duurt namelijk net iets langer als je Cof Assembly pakt.

[Aham brahmasmi]

Eigenlijk niet zo gek, aangezien er steeds meer RAD "programmeurs" inefficiënt met geheugen om gaan, waardoor je amper meer files hebt die minder dan 4KB groot zijn.

Sla maar eens een lege notepad document op (met 1 karakter).

0 bytes, zegt Vista, bij een leeg tekstbestand. Met enkel het karakter '0' erin wordt 'ie meteen 4096 bytes.

@deKeijzer: Ja, maar hij neemt dus al meteen 1 sector van 4KB in (niet 1KB).

[Reactie gewijzigd door Aham brahmasmi op 23 juli 2024 06:48]

[Verwijderd]

Alleen de grootte op de schijf, de werkelijke grootte is toch nog gewoon 1 byte.

[stresstak]

En ook dat lege bestand neemt ergens in een tabel een plekje in. Er moet tenslotte worden bijgehouden dat dat bestand bestaat. Evenals lege directory's/mappen/folders.

[ieperlingetje]

dat een leeg notepad document een relatief grote ruimte aaneemt heeft niks met efficiëntie van de programmeur te maken, maar met de clustergrootte van een bestand.

[brama]

Jammer dat er geen lobby of andere op hef is over het feit dat programmeurs steeds luier en slechter programmeren.

Dit is veel te kort door de bocht. Doordat computers veel sneller geworden zijn, is het mogelijk om veel meer abstracties te introduceren waardoor de programmeur minder werk *hoeft* uit te voeren. Met als extra voordeel dat heel veel fouten afgevangen kunnen worden in de abstractielagen (zoals libraries), die voorkomen dat programmeurs het wiel telkens opnieuw moeten uitvinden. Daarnaast is, doordat ze breed ingezet worden, de kans ook kleiner om fouten te bevatten.

Veel programma's zijn helemaal niet gebaat bij optimalisaties van cpu, bestandsgrootte, e.d. Dat wil niet zeggen dat je dan zo maar wat aan moet prutsen, maar je hoeft echt niet meer elk bitje 3 keer om te draaien

[Verwijderd]

reusability is goed en handig en dus niet wiel opnieuw uitvinden.
Abstractie ook, mits onderliggende lagen maximaal zijn geoptimaliseert.
Als je dan MFC vergelijkt met STL, dan is dat slechts voorbeeld hoe Microsoft omgaat met die zaken en grootste deel van opensource community.

Dus je mag gerust ervan uitgaan dat .NET rad poep is.

[filipy23]

Aan de andere kant, je harde schijf capaciteit neemt ook weer af. Immers, een file van een paar byte wegschrijven kost minimaal 4 KB. De prestatiewinst wordt dus alleen behaald bij bestanden die groter dan 512 bytes.

[mjtdevries]

Dat is alleen maar zo als je je schijf ook geformateerd hebt met een filesysteem dat blocks van 512 bytes gebruikt.

Maar bv NTFS gebruikt standaard al 4KB. Dus dan maakt het niet uit.

[The Realone]

En aangezien dat de meeste bestanden tegenwoordig wel zijn, zal dus winst dus voldoende zijn.

[Calamor]

Als je alleen maar foto's/muziek/films op een HD zet dan ben je wel bij dat je een stuk meer ruimte heb. Ik zou er wel blij mee zijn.

[fdm391]

Dit ligt ook aan het bestandssysteem dat je gebruikt. FAT32 gebruikt bijvoorbeeld standaard al 4kb clusters als ik het goed heb. Dus dan levert het sowieso al geen verlies op, want dat verlies had je al door het bestandssysteem.
Gelukkig zijn niet alle bestandssystemen zo inefficient als FAT32.

Je kunt deze schijven natuurlijk ook alleen gebruiken voor opslag van grote bestanden. Ik zelf heb bijvoorbeeld een 500gb schijf waar vrijwel geen enkel bestand kleiner dan 4KB op staat. Dan zou voor mij de snelheidswinst wel degelijk nuttig zijn.

[El Snorro]

En hoe kunnen alle linux distributies met deze 4kB blokken overweg?

[jcvw]

Ook in Linux is men al lang hiermee bezig. Zie bijv: http://lwn.net/Articles/322777/

[sebastius]

Emulatie van het oude systeem als eerste, en voor de aangepaste het nieuwe systeem

[Verwijderd]

En hoe kunnen alle linux distributies met deze 4kB blokken overweg?

Pas (ongeveer) over 5 jaar gaat men schijven uitbrengen die daadwerkelijk 4kB blokken "communiceren". Linux kan daar dan al lang mee werken (waarschijnlijk nu al, win7/Vista kunnen het bijvoorbeeld ook al).

[pm1]

ik hoop dat ze dit model eerst eens statistisch onderzocht hebben , Want volgens mij wordt de kans op een fout / verloren data een pak groter wordt.

[Reactie gewijzigd door pm1 op 23 juli 2024 06:48]

[Verwijderd]

Vandaar ook de grotere hoeveelheid ECC (per sector)

Werking van ECC wordt bij Advanced Formatting zelfs beter, zie:

http://www.wdc.com/wdprod...papers/en/2579-771430.pdf

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:48]

[GoT]

Heet Windows 2003 wel native support ? (vast niet, maar vraag toch maar voor de zekerheid.)

[Verwijderd]

Nee, heb ik even naar gezocht maar lijkt niet het geval te zijn, ook de x64 versie niet.

Hier nog wat info over alignen:

http://www.ocztechnologyf...um/showthread.php?t=48309

(zie ook de .ppt van MS)

[zanza006]

Ik vind het jmr dat het niet mogelijk is dit toe te passen op reeds bestaande hdd's.

[i-chat]

ik snap ook eigenlijk niet waarom het niet kan, - je zou toch denken dat de firmware bepaalt welke bits gebruikt worden voor x en welke voor y,

best wel een raar verhaal - maar misschien is er iemand die hier iets zinnigs over kan zeggen...

[Verwijderd]

De huidige schijven zijn mechanisch niet instaat te bepalen waar de kop zich bevindt in relatie tot het magnetisch oppervlak (in het XT/AT tijdperk konden ze dat wel). Niet boven welk track en ook niet waar binnen het track. Om hier achter te komen hebben ze een bepaalde indeling van het magnetisch oppervlak nodig zodat ze kunnen zien aan de bits die langskomen waar ze zich bevinden. Deze indeling bepaalt tevens de blokgrote van 512 bytes. Omdat ze van deze indeling afhankelijk zijn kunnen ze deze niet wijzigen omdat ze tijdens het wijzigen dan geen houvast hebben om de nieuwe indeling betrouwbaar en accuraat te schrijven.

[TGEN]

Wat de ECC blokken betreft kan dat wel, maar de genoemde Sync/DAM blokken worden ingebakken in de structuur van de platter tijdens fabricage. Daar zitten bepaalde patronen in waardoor de hardeschijfcontroller ziet wanneer hij bij een nieuwe sector aankomt. Dit is niet aan te passen zonder de platters te vervangen.

[CKSotos]

ik neem aan dat je bedoelt welke voor de 1 en welke voor de 0

[Verwijderd]

niet echt... de disk is een matrix en de indeling is anders als je 4k blokken heb natuurlijk.

[real[B]art]

Dat komt doordat op harde schijven in de fabriek een indeling wordt gemaakt die dient als leidraad voor de lees-/schrijfkoppen.
Die indeling is niet te wijzigen / herschrijven met de koppen, want die zijn afhankelijk van die indeling.

[DukeBox]

Vroeger moest je met mfm controllers nog zelf de indeling bepalen/uitrekenen m.b.v. edlin. Maar ook daar waren er beperkingen aan het OS dat je gebruikte. Je kon toen wel al 'over sizen'. Ik zie niet in waarom dat nu alleen in de fabriek kan. Lowlevel format i.c.m. een andere firmware moet gewoon kunnen lijkt me.

Ik vraag me wel af of (hardware) raid controllers hier mee overweg kunnen.

[Reactie gewijzigd door DukeBox op 23 juli 2024 06:48]

[sensibled]

bedoelt waarschijnlijk debug.exe
commando voor mfm was : g=c800:5

[madsector]

Ah...


Bringing back sweet memories... Heb ooit een 16 bits RLL controller gekocht om m'n schijf te pimpen. Kon ipv 1024 alle 1188 tracks gebruiken, meer sectoren per track (van 17 naar 26) en dat allemaal zonder interleaves..

Kan iemand zich nog Norton Calibrat heugen?

[Verwijderd]

Zullen we het ook nog even over ponskaarten en ponsbanden hebben? Dat waren de echte tijden. Toen waren backup tapes nog van papier. Als die papieren band op een rol zat was het in feite een voorloper van 3 dimensionale gegevens opslag, in tastbare zin.

[Verwijderd]

Kun je de tien geboden nog heugen...? Die werden uitgehakt in steen...dat is pas 3D!

[dgompie]

Ja, maar dat is fiction, haha

[Verwijderd]

@ johncheese002
Interactieve 3D zelfs !!

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:48]

[Verwijderd]

Als je die tapes ook als rol kon uitlezen ipv. de hele tape af te moeten rollen naar dat ene stukje dan was het vast populairder geweest dan het vandaag is. Want dat er veel op een tape past als zgn. "3d opslag" staat vast.

[ASS-Ware]

bedoelt waarschijnlijk debug.exe
commando voor mfm was : g=c800:5

Helaas, dat was RLL.

[ASS-Ware]

mbv Edlin ?
Dat was een text editor, hoe wil je daar mee rekenen ?

[Jasper Janssen]

Het ging om het aanroepen van een bepaald geheugenadres in het bios van de schijfcontroller, dat vervolgens een low level format uitvoerde.

In die tijd werd koppositie nog gewoon bepaald met een stappenmotor, en was er dus ook geen noodzaak om de koppositie dynamisch te bepalen aan de hand van de data die al op de schijf staat. Het is duidelijk dat bij een dergelijke schijf het niet mogelijk is de kopen -- althans niet zomaar -- te gebruiken voor LLF. Waarschijnlijk wordt het in de fabriek gedaan door positionele feedback te voorzien dmv een directe meting op koppositie, of door de koppen mechanisch te laten aansturen door een externe motor.

[JoJo_nl]

de indeling van de formattering , niet de fysieke schijfindeling.

[Verwijderd]

Neemt de read/write performance ook toe doordat er minder headers moeten worden gelezen/geschreven of begrijp ik het dan verkeerd?

[the_stickie]

Het zall wat afhangen van de situatie. Een 2KB bestand uitlezenvergde voorheen het uitlezen van 4 sectoren van elk 512 bytes. Nu is dat 1 sector va 4KKB. In dat geval lees je dus eigenlijk veel te veel data en zakt de performantie.
Ik gok dat in deze tijden van Terrabyte schijven en Gigabyte bestanden, het in de praktijk niet zoveel gaat uitmaken. Mocht de winst significant zijn, zouden ze er wel mee uitpakken denk ik dan.

[_JGC_]

Pagesize op de meeste architecturen is 4K. Blocksize voor NTFS en ext3/4 is over het algemeen ingesteld als een veelvoud van 4K. Het heeft dus tegenwoordig weinig zin om nog met 512 bytes per sector te werken.

[Kixtart]

Maar dit betekent wel dat de interne fragmentatie een stuk groter wordt? Bij een DataHD waar je alleen films en series opzet zou het een stuk beter zijn, maar programma's en Windows zelf gebruiken vaak veel kleine bestandjes (bijv logs), dus daar verlies je mogelijk veel. Ook als een file over meer blokken verdeeld wordt zal het laatste blok ipv max 511 fragmentatie zelfs max 4095 bytes fragmentatie hebben.

Of ik beredeneer het volledig verkeerd

[Reactie gewijzigd door Kixtart op 23 juli 2024 06:48]

[dog4life]

Enigszins verkeerd, fragmentatie houdt in dat de datablokken die door een bestand gebruikt worden, verspreid over de schijf liggen.
Heb je nu een bestand van 513 bytes, dan had je in het verleden kans op fragmentatie: de 2 blokken zouden verspreid kunnen liggen. Nu is het 1 datablok, dus geen kans meer op fragmentatie voor dat bestand/blok (in dit geval hetzelfde).
Ik denk dat als we spreken over bestanden van > 100MB dat de kans op fragmentatie ook minder is, aangezien er minder datablokken benodigd zijn.

[Kixtart]

Enigszins verkeerd, fragmentatie houdt in dat de datablokken die door een bestand gebruikt worden, verspreid over de schijf liggen....

Ik heb het over de interne fragmentatie van een cluster. Als je nu een bestand maakt van één enkel karakter dan zal deze 512bytes groot worden, terwijl het in principe in 1byte zou passen als de cluster die grootte was geweest. Nu heb je dus het probleem dat 4096bytes gebruikt wordt in dat geval.

[Aham brahmasmi]

Maar dit betekent wel dat de interne fragmentatie een stuk groter wordt?

Ja, als je het hebt over sub-sector fragmentatie van ongebruikte ruimte, dan wel.
De ongebruikte ruimte in sectoren waar kleine bestanden in staan kan niet voor andere bestanden gebruikt worden. Dat betekent dus dat er hele kleine stukjes lege ruimte gefragmenteerd worden, maar dit veroorzaakt in de praktijk enkel een verlies/verspilling van vrije ruimte. Het is niet zo dat door de vrije ruimte in sectoren, er veel meer zoek-acties gedaan moeten worden door de leeskoppen, dus er is praktisch geen prestatieverlies hierdoor.

[Reactie gewijzigd door Aham brahmasmi op 23 juli 2024 06:48]

[Kixtart]

Ja, ik had het interne fragmentatie genoemd, omdat de defrag van windows dat ook zo aangeeft gewoonlijk. Zelf had ik het niet over snelheidsverlies, maar het artikel had het over 7%-10% capaciteitswinst, dus vroeg het me af of dat in de praktijk ook snel zou zijn.

[Snow_King]

Bij SSD's lopen ze hier ook al langer tegenaan, zo wordt er daar ook al langer over gesproken.

Gaat dit ook niet meer IOps aankunnen doordat de RAID Controller (als je die gebruikt) minder werk hoeft te doen bij het berekenen van ECC / pariteiten?

[Big Womly]

Als ik me niet vergis worden de pariteiten berekend op het bestand "as is" en heeft de manier waarop het bestand wordt weggeschreven naar de schijf hier geen invloed op.

[.oisyn]

RAID en z'n pariteiten hebben niets met de individuele bestanden van doen. Een RAID controller ziet die bestanden ook niet, die krijgt gewoon blokken data binnen en doet daar wat mee.

[Carbon]

Gaat dit ook niet meer IOps aankunnen doordat de RAID Controller (als je die gebruikt) minder werk hoeft te doen bij het berekenen van ECC / pariteiten?

Nee, want de sector ECC's worden berekend/gecontroleerd door de HDD.

[Reactie gewijzigd door Carbon op 23 juli 2024 06:48]

[jvr]

begrijp ik dan goed dat een schijf die nu als 1TB wordt vekocht ,over de toonbank gaat voor 1,5TB.
Eigenlijk is dat wel raar,immers het aantal magnetische velden blijft het zelfde

[ZpAz]

7-11 procent, dus laten we zeggen max 1.1TB.

[dog4life]

Als je het artikel leest niet, 7 tot 11% is geen 0,5TB, dat is namelijk 50% van 1TB.