If-Koubou

Miksi on olemassa suuri ero "Koko" ja "Koko levyllä"?

Miksi on olemassa suuri ero "Koko" ja "Koko levyllä"? (Miten)

Suurimman osan ajasta "Koko" ja "Koko levyllä" olevat arvot ovat hyvin lähellä sovitusta, kun tarkistetaan kansion tai tiedoston kokoa, mutta mitä jos näiden kahden välillä on valtava ero? Tämän päivän SuperUser Q & A -viesti käsittelee vastausta tähän sekavaan ongelmaan.

Tämän päivän kysymys- ja vastausistunto tulee meihin SuperUserin hyväksi - Stack Exchangein alaosasto, joka on yhteisöllinen Q & A-sivustojen ryhmittely.

Kysymys

SuperUser-lukija thelastblack haluaa tietää, miksi on olemassa niin suuri ero "Koko" ja "Koko levyllä" kansion puhelimen SD-kortille:

Kuten alla olevista kohdista käy, on niin paljon eroa tämän kansion "Koko" ja "Koko levyn" kenttien välillä. Miksi niin?

Tiedän, että "Koko levyllä" pitäisi olla hieman enemmän kuin "koko", koska jakamisyksiköt Windowsissa, mutta miksi siellä on paljon eroa? Voisiko se olla tiedostojen suuri määrä?

BTW, tämä kansio on Android-puhelimen SD-kortilla. Tämän sisällä karttasovellus tallentaa välimuistit kartat ja sovellus saa kartat Google Mapsista.

Kun katsot kuvakaappausta, on äärimmäisen suuri ristiriita "Koko" ja "Koko levyllä", joten mitä on tapahtunut täällä?

Vastaus

SuperUser-avustajalla Bobilla on vastaus meille:

Oletan, että käytät FAT / FAT32-tiedostojärjestelmää täällä, koska mainitset tämän SD-kortin. NTFS ja exFAT käyttäytyvät samalla tavoin jakeluyksiköiden osalta. Muut tiedostojärjestelmät voivat olla erilaisia, mutta niitä ei kuitenkaan tueta Windowsissa.

Jos sinulla on paljon pieniä tiedostoja, tämä on varmasti mahdollista. Harkitse tätä:

  • 50 000 tiedostoa
  • 32 kt: n klusterikoko (allokointiyksiköt), joka on maksimissaan FAT32: lle

Ok, nyt minimi tilaa otettu on 50 000 * 32 000 = 1,6 Gt (käyttäen SI-etuliitteitä, ei binaarisia, yksinkertaistamaan matematiikkaa). Aina, jokaisen tiedoston vie levy, on aina allokointiyksikön koon monta - ja täällä oletamme, että jokainen tiedosto on oikeastaan ​​tarpeeksi pieni, jotta se sopisi yhteen yksikköön, jossa jäljelle jäänyt (hukkaan) tila.

Jos jokainen tiedosto on keskimäärin 2 kt, saat noin 100 Mt kokoa - mutta olet myös tuhlaa keskimäärin 15 kertaa (30 kt / tiedosto) jakamisyksikön koon vuoksi.

Syvällinen selitys

Miksi näin tapahtuu? No, FAT32-tiedostojärjestelmässä pitää seurata, mistä kukin tiedosto on tallennettu. Jos jokaisen yksittäisen tavun pitäisi olla, taulukko (kuten osoitekirja) kasvaisi samalla nopeudella kuin tiedot - ja jätettäisiin runsaasti tilaa. Joten he käyttävät "allokointiyksiköitä", joita kutsutaan myös "klusterikokoiksi". Tilavuus jaetaan näihin allokointiyksiköihin, ja tiedostojärjestelmän osalta niitä ei voi jakaa - ne ovat pienimmät esteet, jotka se voi käsitellä. Paljon kuin sinulla on talon numero, mutta postimies ei välitä kuinka monta makuuhuonetta sinulla on tai jotka asuvat heistä.

Joten mitä tapahtuu, jos sinulla on hyvin pieni tiedosto? Tiedostojärjestelmä ei välitä, jos tiedosto on 0 KB, 2 kt tai jopa 15 kt, se antaa sille pienimmän mahdollisen tilan - yllä olevassa esimerkissä 32 kt. Tiedostosi käyttää vain pienen määrän tätä tilaa, ja loput ovat periaatteessa hukkaan, mutta silti kuuluu tiedostoon - paljon kuin makuuhuone, jonka jätät tyhjiksi.

Miksi eri kokoamiskokoja on olemassa? No, se muuttuu suuremmaksi taulukoksi (osoitekirja, esim. Sanotaan John omistaa talon 123 Fake Street, 124 Fake Street, 666 Satan Lane jne.) Tai enemmän hukkaan tilaa jokaisessa yksikössä (talo) . Jos sinulla on suurempia tiedostoja, on järkevämpää käyttää suurempia kohdennusyksiköitä - koska tiedosto ei saa uutta yksikköä (taloa), kunnes kaikki muut täytetään. Jos sinulla on paljon pieniä tiedostoja, niin sinulla on suuri taulukko (osoitekirja) joka tapauksessa, joten saat myös pienille yksiköille (talot).

Suuret jakoyksiköt pääsääntöisesti jättävät paljon tilaa, jos sinulla on paljon pieniä tiedostoja. Yleensä ei yleensä ole hyvä syy ylittää 4 kt.

Hajanaisuus?

Pirstaleisuuden osalta hajanaisuus ei saisi tuhlata tilaa tällä tavalla. Suuret tiedostot voivat olla hajanaisia, eli jakautuneet useisiin kohdennusyksiköihin, mutta jokainen yksikkö on täytettävä ennen seuraavan aloittamista. Defragging saattaa säästää vähän tilaa jakotustaulukoissa, mutta tämä ei ole sinun erityinen ongelma.

Mahdolliset ratkaisut

Kuten gladiator2345 ehdotti, ainoat todelliset vaihtoehdot tässä vaiheessa ovat elää sen kanssa tai uudistetaan pienemmillä kohdennusyksiköillä.

Korttisi voi olla alustettu FAT16: ssä, jolla on pienempi pöydän koon raja ja vaatii siksi paljon suurempia kohdistusyksiköitä, jotta voidaan käsitellä suurempaa äänenvoimakkuutta (jonka yläraja on 2 Gt ja 32 kt: n kohdistusyksiköt). Lähdekoodi Braiamilta. Jos näin on, sinun pitäisi pystyä muodostamaan turvallisesti muotoon FAT32 joka tapauksessa.

Onko jokin asia lisättävä selitykseen? Kuulkaa kommentit. Haluatko lukea lisää vastauksia muilta tech-tajuilta Stack Exchange-käyttäjiltä? Katso koko keskusteluketju täältä.