Varför visas 2TB Hårddisk som 1,74 TB.

har du kollat så den inte har en gömd partition?

2×1000^6/1024^6

@Soldierofwar1985: Nej du är inte lurad, en del av utrymmet tas upp av filsystem och liknande.

Nä. Så funkar det. Har du den som systemdisk också så kan det försvinna lite till. Det är bara ett annat sätt att räkna som Windows gör (som alla andra också sagt).

Filsystemet tar faktiskt plats på HDD/SSD, kan ju iofs hålla med om att det inte skall ta så stor plats, sen vet jag också att det är något med hur dom räknar men kunde inte beskriva det och därför fick med bli mm.

Sen vet jag faktiskt inte om tillverkarna numera redan räknat med det utrymmet som filsystem tar, förr vet jag det inte var med.

Men poängen med mitt inlägg var att det är som det skall

Det har inte nått med "filsystem" att göra utan att man använder prefixen slarvigt och blandar tebibyte med terabyte.
Kollar man på antalet bytes så får man ett korrekt värde och ska man använda prefix så behöver man skilja på vilken bas talsystemet de utgår från använder för att det ska bli rätt.
https://en.wikipedia.org/wiki/Tebibyte

Då lever jag kvar i det förgångna eftersom jag vet att det snackades förr om att filsystemet tar en viss plats, efter det har jag aldrig reflekterat vidare över det, men man brukar kunna räkna bort ca 10% av det som själva disken anger.

Så, hoppas alla nöjda..

Det må ha snackats om det, men det har aldrig stämt. Folk får för sig grejer som med tiden blir populära myter.

Att det är just 10 % man kan "räkna bort" beror på att hårddiskar är i storleksordningen 1 TB just nu och att 1 TB är ungefär 91 % av 1 TiB. Men diskrepansen mellan decimala och binära enheter växer när storlekarna vi diskuterar växer. 1 kB är hela 98 % av 1 KiB och 1 EB bara 87 % av 1 EiB.

Har inget att göra med NTFS, FAT eller något annat filsystem, eller formatering överhuvudtaget. Tillverkarna anger storleken i TB; Windows anger i TiB men skriver "TB". MacOS och de flesta Linuxsystem gör (vad jag anser är) rätt.

Varför krånglar ni till det... hårddisktillverkare räknar med 1000, 1000 byte på 1 Kilobyte, 1000 Kilobyte på 1 Megabyte o.s.v., datorer har alltid räknat binärt, så 2 i bas. 1024 byte på 1 Kilobyte o.s.v., därav uppkommer diffen. Rent marknadsföringsknep från början till slut som numer blivit så pass märkbart p.g.a. dagens hårddiskstorlekare.

Sen att MacOS/Linux anpassat sig till hårddisktillverkarna för att användarna inte ska känna sig lurade...

Hårddisktillverkare har alltid räknat så, och de har rätt.
Det enda i datorer som "alltid" använt de binära prefixen är primärminne, och då till stor del pga att hur minnena är designade så är deras storlek nästan alltid baserade på en två-potens.
Det mesta annat i datorer använder sig av de vanliga SI-prefixen.

Huh? Allt i datorer har ju varit binärt från början till slut, så att räkna med SI-prefix är ju något som dök upp efter hårddiskar dök upp.

Nej, nej, helt fel.
Klockfrekvenser - vanliga SI prefix används där
Överföringshastigheter, både för nätverk och hårddiskar, och interna databussar - vanliga SI-prefix används där
Lagringsenheter - SI-enheter från början, men snare så började binära prefix användas här och där också. Det var inte förrän en bra bit in på 80-talet som operativsystem började använda binär-prefix för att vissa storlekar på filer och diskar, innan dess så gjordes detta ofta i exakt antal bytes.

Det stämmer som sagt inte alls, Wikipedia har en artikel om binära prefix genom historien.

Solklart..., verkar ju vara först efter 2010 som tillverkare slutade vackla från ena hörnet till det andra, men jag ”stand corrected” då.

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

Jag minns att folk har ställt samma fråga på forumet i typ 20 år. Kul att det fortfarande blir en lång diskussion med folk villiga att hjälpa!

Jag brukar alltid bara tänka att tillverkaren anger 1000KB som 1000KB medans windows anser att 1000KB = 1024KB (med risk för att det är tvärtom och att jag inte har full koll på den tekniska/matematiska förklaringen bakom.

Men nej, det är som det ska.
Sen kan det finnas dolda återställningspartitioner också.