Diskuze: MB vs MiB
Člen
Zobrazeno 18 zpráv z 18.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
MiB = 1024KiB = 10242 B
MB = 1000KB = 10002 B
MB se používají na discích (vypadají větší).
MiB se používají v aplikacích a je praktičtější používat jednotky
založené na násobcích dvou (v tomto případě 210).
A pak je tu řada případů kdy to někdo používá blbě...
Ještě zbývá dodat, že ty jednotky s "i" se čtou kibibajty mebibajty gibibajty tebibajty je to jako kilo binary, mega binary, giga binary ...
Obzvláště výrobci HDD, SDD, a možná už i flashek si libují v tom určovat velikost v GB. Takže zákazník dostane nádherných 500 GB prostoru, no ale když to otevřeš kupříkladu ve Windows exploreru (Tento počítač), tak zjistíš, že máš reálně cca 465 GB prostoru. A čím větší disk, tím víc tě oškubou
hlavně nesmíš zapomenout na to že 8 hobitů je jeden hobyte.
V češtině se málokdy používá MiB (bohužel).. Ale prakticky každý (kromě již zmíněných výrobců disků) říká MB a myslí MiB
často souborovým systémem. Na startu bývají různé tabulky co žerou nějaké místo.
Podle mě to Windows neukazuje - stačí kalkulačka: 500 GB převedeš opravdu na 465 GiB, což je přesně ukazovaná hodnota. Nerýpal jsem se v NTFS úpně hluboko, ale MFT si pro sebe jen rezervuje prostor (zabraňuje zápisům do prvních 50 % disku) - ale jakmile dojde těch druhých 50 % (kde jsou data), rezervace se prostě zmenší (na polovinu). Tak to jde až do 12,5 %, a potom nevím, jak přesně to funguje, když se disk zaplní.
Tak, v MFT máš i při prázdném svazku určité soubory již přítomné, zejména ty s metadaty:
nedávno jsem zkoušel formátovat 64 MB RAM disk přes NTFS a dostal jsem cca 48 MB volného místa. Není to ale tak, že by si NTFS ukrojilo čtvrtinu svazku a zabralo si jej, prostě není efektivní na malých prostorech.
Dobře, case study pro můj počítač. Systémový disk, ext4:
Inodů - 290155 a 256 bytů na inode, čili 74279680 bytů (74 MB)
Dobře, 74 MB metadat na systémovém disku. Disk má 240 GB (Ano, GB, ne GiB), čili 223 GiB. Pokud dobře počítám, mělo by to vycházet asi na 0,03 %. A to mám extended attributes (256 bytů na inode, kvůli ACL a SELinux).
Jaké jsou zdroje těchto informací (třeba zrovna ty deskriptory zabezpečení)? - nějaké dobré a podrobné a přesné počtení
Takže například v tomto videu, je to špatně a jednotky by měly být v MiB atd...?
Tady je neoficiální dokumentace NTFS
https://jadro-windows.cz/materialy/ntfs/
Původně na linux.ntfs.org, ale dovolil jsem si být ošklivý a dát ji i k sobě. Nejsem si jistý, zda-li na původním zdroji ještě je k dispozici.
Každopádně tam je vidět, jak vypadá MFT záznam, jaké struktury se na něj navěšují, jaké jsou soubory metadat... AFAIK se tam nic nepíše o tom, jak vypadá prázdný svazek, ale to půjde trochu odvodit.
Dobře, case study pro můj počítač. Systémový disk, ext4: inodů - 290155 a 256 bytů na inode, čili 74279680 bytů (74 MB)
U EXT4 ti to bude možná zobrazovat trochu jiné informace, protože tam není sdíleno volné místo mezi tabulkou inodů a daty souborů jako v NTFS, ale je předem dáno (tak jsem to aspoň pochopil), kde je prostor pro inody. U NTFS se volné místo sdílí s daty souborů a MFT. U FAT třeba zase ne (vyhrazený prostor pro tabulky FAT, popř. pro kořenový adresář u FAT12/16).
Windows to zobrazuje "špatně". Píše MB, GB, TB atd., ale počítá MiB, GiB, TiB atd. Proto když jsem si pořídil 2 TB externí HDD, tak v Linux Mintu to mělo skutečně 2 TB, ale na Windowsu 1,81 TB, přičemž to má 2 TB = 1,81 TiB.
Převod je, jak je tedy již řečeno, po 1000 pro kB, MB, GB, TB apod. a po 1024 pro kiB, MiB, GiB, TiB apod.
Zobrazeno 18 zpráv z 18.