Mobili versija | Apie | Visos naujienos | RSS | Kontaktai | Paslaugos
 
Jūs esate čia: Pradžia » Visos temos » Technologijos » IT

Bitai ir baitai. Trečia dalis: kas yra NTFS bei FAT formatai ir kodėl failas diske užima daugiau vietos, nei jo tikrasis dydis

2016-09-26 (16) Rekomenduoja   (57) Perskaitymai (3373)
    Share
Tai straipsnis iš rašinių ciklo. Peržiūrėti ciklo turinį

Tie kas bent karta žiūrėjo į failo savybių kortelę, joje matė kad failas turi du dydžius: realų failo dydį ir failo dydį atminties laikmenoje. Kurie daugiau arba mažiau skirtingi. Ir kai kurie pagalvojo, kodėl jie skiriasi ir koks yra tikrasis failo dydis. Tikrasis failo dydis yra tas mažasis skaičius, o didesnis skaičius rodo ne failo dydį, bet kiek jis užima vietos duomenų laikmenoje. Taip yra dėl to, kaip veikia failo išsaugojimas duomenų laikmenoje.

Manau visi yra girdėję, kad Windows operacinės sistemos kietasis diskas turi būti suformatuotas NTFS formatu. Ir kas naudojasi kompiuteriais seniai, žino kad buvo naudojama FAT formatavimas (jis nepamirštas ir dabar, bet užleidžia vietą NTFS formatui). Kam teko formatuoti kietąjį diską arba USB raktą, žino, kad galima pasirinkti ne tik formatą, bet ir rezervuoto sektoriaus (allocation) dydį. Standartiškai NTFS failų sistemai yra paskirtas 4096 baitų rezervuotas sektorių dydis, bet galima rinktis ir didesnius dydžius (8192 baitų, 16 kilobaitų ir t.t.). Egzistuoja daugiau failų sistemos standartų, ne tik FAT ir NTFS.

Jei jūsų duomenų laikmena suformatuota NTFS formatu ir rezervuotas sektoriaus dydis yra 4096 baitų ir joje išsaugosite 1000 baitų failą, tai jis duomenų laikmenoje užims 4096 baitus. Jei išsaugosite failą kurio dydis 3000 baitų, tai jis duomenų laikmenoje vis tiek užims 4096 baitus. Nes abu šie failai telpa į rezervuoto sektoriaus atminties dydį. Jei turite du failus po 1000 baitų, tai jie abu duomenų laikmenoje užims 8192 baitus. Nes į rezervuotą sektorių negalima įrašyti dviejų skirtingų failų. Jei failo realus dydis yra 6000 baitų, tai duomenų atmintyje jis užims 8192 baitus. Nes jis pilnai užpildys viena rezervuota sektorių ir dalį antro rezervuoto sektoriaus. Bet kadangi į laisvą antro rezervuoto sektoriaus dalį kito failo išsaugoti nebegalima, jie abu priskiriami tam failui. Jei duomenų laikmena bus suformatuota 16 kilobaitų rezervuotais sektoriais, tokioje laikmenoje išsaugojus 1000 baitų dydžio failą, jis užims 16 kilobaitų dydį.

Gali kilti klausimas, kodėl yra sukurti tokie dideli rezervuoti sektoriai, jei jie taip švaisto vietą. Atsakymas labai paprastas. Kuo toliau, tuo visi failai tampa didesni. Ir dauguma dabartiniu failų yra megabaitų dydžio. O kai kurie failai yra net gigabaitų dydžio. Todėl jei suformatuosime duomenų laikmeną NTFS formatu ir 16 kilobaitų rezervuotais sektoriais ir tokioje laikmenoje išsaugosime 1 gigabaito failą, tai iššvaistyta vieta neviršys 16 kilobaitų. Lyginant su viso failo dydžiu, tai yra labai mažas ir nereikšmingas praradimas. Bet kuo didesni rezervuoti sektoriai tuo greičiau galima pasiekti failą duomenų laikmenoje. Nes mažėja failo fragmentacija į skirtingus sektorius. Dauguma vartotojų gali palikti standartinį rezervuoto sektoriaus dydį, bet jei į konkrečia duomenų laikmeną planuojama dėti tik didelius failus, galima pasirinkti ir didžiausią rezervuotų sektorių dydį.

Taip pat gali skirtis ir failo dydis darbinėje kompiuterio atmintyje nuo jo realaus dydžio ar jo dydžio duomenų laikmenoje. Nes dažnai failai yra suspaudžiami įvairiais algoritmais, kad užimtų kuo mažiau vietos duomenų laikmenoje. Bet failą įkėlus į kompiuterio darbinę atmintį ir su juo dirbant, jį tenka išskleisti. Geras pavyzdys yra paveiksliukai. Yra sukurta daug skirtingu jų formatų bmp, png, jpg ir t.t. Vieni formatai visiškai nesuspaudžia paveiksliuko, kiti jį suspaudžia daugiau ar mažiau. Bet norint šiuos paveiksliukus peržiūrėti ar juos redaguoti, juos reikia įkelti į kompiuterio darbinę atmintį ir išskleisti, kad butu galima matyti ir redaguoti kiekviena paveiksliuko pikselį.

Pavyzdžiui, GIMP programa sukūriau tuščią (baltą) 5000×5000 px paveiksliuką ir jį išsaugojau bmp, png ir jpg formatais. GIMP rodo kad šis paveiksliukas kompiuterio darbinėje atmintyje užima 238,9 MB. BMP formatu išsaugota jo kopija duomenų laikmenoje užima 75 001 856 baitus, o failo realus dydis yra 75 000 122 baitai. JPG formato kopija atitinkamai yra 294 912 ir 293 756 baitai. PNG formato kopija – 86 016 ir 84 347 baitai. Visų trijų formatų failų dydis skirtingas, nes jie skirtingai sugeba suspausti informaciją konkrečiame paveiksliuke. Ir jų dydis duomenų laikmenoje skiriasi nuo realaus dydžio dėl rezervuotų sektorių dydžio į kuriuos yra suformatuota mano duomenų laikmena. Bet visus tris paveiksliukus vėl įkėlus į GIMP programinę įrangą jie visi užima tiek pat (238,9 MB) vietos darbinėje kompiuterio atmintyje.

Dėl failo suspaudimo ir duomenų laikmenos formatavimo skiriasi to paties failo užimama vieta duomenų laikmenoje ir kompiuterio darbinėje atmintyje. Jo realus dydis bus dar kitoks.

Čia užsiminiau apie skirtinga failo suspaudimą, o jei tiksliau, skirtingą informacijos suspaudimą. Išskleistas paveikslėlis darbinėje kompiuterio atmintyje yra savo pradinėje informacijos formoje. O bmp, png ir jpg formatai, kuriais jie yra išsaugoti duomenų laikmenoje, yra šios informacijos suspaudimo metodai. Ir pačiu pirminiu failo dydžiu galima vadinti informacijos dydį darbinėje atmintyje, o failus duomenų laikmenoje galima lyginti su duomenų laikmenos formatavimu – kokio dydžio rezervuoti sektoriai 4 KB ar 16 KB. Bet tai visiškai atskira tema. Apie ją galima prirašyti romanus.

Donatas Azaravičius

Verta skaityti! Verta skaityti!
(58)
Neverta skaityti!
(1)
Reitingas
(57)
Visi šio ciklo įrašai:
2016-09-26 ->
Bitai ir baitai. Trečia dalis: kas yra NTFS bei FAT formatai ir kodėl failas diske užima daugiau vietos, nei jo tikrasis dydis
2016-09-25 ->
2016-09-24 ->
Komentarai (16)
Komentuoti gali tik registruoti vartotojai
Kiti tekstai, kuriuos parašė Donatas Azaravičius
Naujausi įrašai

Įdomiausi

Paros
59(5)
39(0)
32(0)
19(0)
13(0)
12(1)
Savaitės
135(13)
128(12)
86(1)
85(7)
83(6)
Mėnesio
139(3)
139(0)
135(13)
134(2)
132(10)