Man har alltid räknat lagringsutrymme i decimal form då man räknar i antal dataposter som kan lagras och med dagens diskar med dataposter just i byte-storlek - men var inte alls givet då dataposter kunde vara i 4-bitars storlek eller 7, 10, 12 eller 14 bitars storlek anpassade efter använda datorers databandbredd och arkitektur i sina operationer där ett kilo data-ord betydde just 1000 data-ord av en viss storlek (skriver man assembler för PIC-processorer så lär man sig snart att ett dataord är inte 8 bitar utan kan vara 12 bitar). Samma tänk gäller i dataöverföring där 1 Mbit/s är just 1000000 bit/s - inte 1048576 bit/s.
Gamla ST506-diskar och några storleksgenerationer uppåt på MFM-diskarnas tid så var det helt sant att man räknade diskens storlek i antalet möjliga flux som skivan kunde lagra med antalet spår, varvtal 3600 rpm och 2.5 MHz skrivtakt (= 5 Mega flux/s) till skriv/läshuvudet.
En ST506-disk definierade sig med 6.38 Megabyte i storlek uppdelat i 10416 bytes per spår ( 83328 bit eller flux per spår) fördelat på 153 spår, 4 diskytor (vilket ger totalt 612 spår) och total storlek av 6374593 Byte.
efter formatering med 256 bytes sektorer så hade man 8192 Bytes per spår uppdelat på 32 sektorer, 153 spår och 4 cylindrar ger då 5013504 byte (5.013504 MB) vilket blir 4.78126 MiB.
med 512-bytes sektorer så brukar man få in 17 sektorer vilket ger 8704 byte per spår och med samma antal spår ger det då 5326840 byte eller 5.08 MiB
På den tiden bestämde man också vid formatering om man skulle ha 128, 256, 512, och ibland tom. 1024 bytes sektorer på disken (samma sak kunde man göra på disketter) om det fans tillräckligt mycket RAM på diskkontrollerkortet - vilket också innebar ju mindre sektorer man valde, ju mer diskyta gick till spillo till spårnummer, sektoradress, GAP, GAP3, checksummor etc. så där tävlade man mellan hur väl man kunde fylla varje sektor gentemot många små sektorer för många små filer.
Vanligaste sektorstorleken på CP/M-tiden var 256 bytes sektorer, 512-bytes sektorer kom med MS-DOS på mitten av 1980-talet och klamrar sig fast ännu idag med emulerade versioner då i princip ingen modern arkitektur räknar i mindre än 4-KiB sektorer från minsta cache-segmentet i CPU ända ut till datatransporten mot diskarna. - det finns dock ett aber - SATA-bussen hanterar bara 512-bytes sektorer och tex. 4 KiB logiska sektorer måste emuleras med 8 st 512-bytes sektorer i själva överföringen trots att alla moderna hårddiskar har idag 4KiB sektorer som minsta fysiska sektor.
I och med SCSI-diskar snart kom med kontrollerkortet redan orginalmonterad på disken (innan dess var det ett tillbehör som kopplades till diskens kontrollerkort av ST506-gränssnittstyp i en kortformat som kunde skruvas på direkt på diskens kretskorts-sida) och kort senare IDE-diskar, så slutade man att räkna hur mycket rådata skivorna innehöll före lågnivåformatering utan istället var det ett fixt värde i antal sektorer baserad på sektorstorlek (standard 512 byte), antal sektorer per spår, antal cylindrar och antal spår (CHS-adresseringen - innan det ersattes med dagens LBA-adressering) - och även frihet att välja sektorstorlek försvann[1] och i samband med detta så försvann också möjligheten till 'riktig' lågnivåformatering.
På en hyfsat modern 512-bytes sektor-disk så har man på ett spår, per sektor 15 byte utrymme för GAP, sync, adress mark och GAP3, därefter användardata på 512 byte och omedelbart därefter 50 byte i ECC-kod vilket ger att att varje sektor tar upp 577 byte på diskytan - med detta får man en ytfyllnad på 88.7% användbar data av totala antalet tillgängliga flux.
Med native 4K-sektorer så är det även där 15 bytes för GAP, sync, adress mark och GAP3, 4096 byte användardata och därefter 100 Byte ECC-data - vilket ger en ytfyllnad på 97.3% användbar data av antalet tillgängliga flux. - kort sagt gå från 512 bytes native sektor till 4K native sektor så kunde man fylla disken med nästan 11% mer data på samma antal tillgängliga flux.
GAP och GAP3 är områdena precis innan och efter skrivna användardatat och dess ECC för att ge synkningstid för PLL för datat som kanske inte ligger riktigt i fas med adressfälten precis strax innan och armbågsrum om skrivningen inte gick riktigt med samma hastighet som när orginalformateringen gjordes samt ger ett område före och efter där man kan växla mellan skrivning och läsning utan att det riskera att skriva över någon viktig data (som CRC-summor i adressfält om växlingen till skrivning startar för tidigt inpå)
Det var ganska mycket i marginaler om man tittar hur en ST506 MFM-disk formaterades med typ 69.5 byte per 256-bytes sektor som försvann i 'adminstration' kring sektorerna i form av adressfält, CRC-summor GAP1, GAP2, GAP3 och GAP4 och bara 78.6% av fluxen tillgänglig för användardata - i moderna diskar har man plockat bort det mesta av GAP-fälten med mer exakt och mer följsam klockning men samtidigt har man ökat på fälten med ECC-kod (istället för CRC) ordentligt (50 byte per 512-bytes sektor, 100 Byte per 4K-sektor)
[1]
har till viss grad återkommit igen för SAS-diskar för extra paritetsdatafält för 512 bytes sektorer (512, 520 och 528 bytes sektorer) och 4k-sektorer (4096, 4112, 4160 och 4224 bytes sektorer) och många av SAS-diskarna kan man i efterhand formatera om mellan de olika 512-bytes storleksklasserna respektive 4k-storleksklasserna