Kovalevytila

[petteriIII]

Iso kansio vie talletettaessa kovalevytilaa erilaisilta levyiltä erilaisia määriä. Onko ohjelmia jotka osaavat ennakoida tämän?

- siis tavallaan haluaisin seuraavankaltaisen käskyn: talletuskoko kansio_polkuineen levy
- siis käytännössä kirjoitettaisiin esimerkiksi: talletuskoko /home/käyttäjänimi sda

- voisihan itsekin väsätä tällaisen skriptin. Mutta siinä olisi iso työ, ja salahautoja olisi vilisemällä. Niinkuin esimerkiksi btrfs-tiedostojärjestelmä.
- tosiaan: käsky du vie ihan metsään.

[jekku]

Onpahan sellainen kutina että btrfs-tiedostojärjestelmällä on omat työkalunsa noihin hommiin.

[petteriIII]

Tuon kovalevyn talletustilan laskemisessa luottaisin eniten gparted:iin sillä se on vuosien varrella kertonut kovalevytilasta mielestäni poikkeuksetta luotettavasti. Mutta kun käsky:du ja tiedostoselain nautilus väittävät  saman kansion kooksi noin 31M ja gparted 44M niin kummalta tuntuu.
- tiedostomuoto oli kokoajan EXT4.

- yhdellä verkkosivulla oli lueteltuna miljoona syytä miksi teoria ei täysin vastaa käytäntöä talletustilaa määrättäessä - olisikohan tässä kyse siitä?

[Tomin]

Siis onko tuo hakemisto ainut siellä levyllä ja du (ja kumppanit) näyttää eri koon sille hakemistolle kuin mitä tiedostojärjestelmästä on varattu tilaa (GPartedin lukema)?

[petteriIII]

Alunperin tilanne oli tuo.  Mutta koska se tosiaankin on mahdollinen vikalähde niin tarkistin että tilanne pysyy samana kun sen tikulla olevan kansion kopioi siihen viereen (kopion jotta koko olisi varmasti sama).

Toimet: jotta saisin tilanteen jossa talletusväline on alussa tyhjä niin alustin gpartedilla muistitikulle yhden osion. Osion luomisen yhteydessä katsoin minkäverran osiolta on varattu pääkäyttäjälle tilaa ja sitä oli varattu 37M.
Sitten kopioin kovalevyltä OMATSKRIPTIT kansion tikulle ja katsoin gpartedilla minkäverran tilaa nyt oli varattu ja sitä oli varattu 81M. Ero on siis 44M.
- OMATSKRIPTIT-kansio on ihan normaali kansio jossa on lukemattomia tiedostoja omissa kansioissaan ja mukana on runsaasti pieniä, muutaman sanan kokoisia tiedostoja

Sitten ajoin käskyn: du /media/petteri/tikku/OMATSKRIPTIT ja se antoi tulokseksi 31797970   
- muuten nautiluksella katsottaessa OMATSKRIPTIT-kansion  ominaisuuksia niin tilaksi ilmoitettiin 31.7M.

- tuon tuloksen 44M sai myös kun ajoi ohjelman: pydf kun tikku oli tyhjä ja vertasi sitä siihen kun OMATSKRIPTIT oli kopioitu tikulle.

- on ihan mahdollista että en osaa tulkita kaikkea oikein. Mutta verkosta noita talletustila-juttuja lukiessa selvisi että talletustilan mittaaminen on vaikeaa sillä on käyttöjärjestelmän asia miten se bitit levylle kirjoittaa. Siis käyttöjärjestelmä itse tietää kyllä paljonko se silläkertaa tallettamiseen kulutti mutta sehän on vain yksi luku eikä monelle riville eritelty jollaisena du sen esittää.

[Tomin]

Tiedostolla on tiedostojärjestelmässä minimikoko, joten paljon pieniä tiedostoja voi viedä enemmän tilaa kuin niissä on tietoa.
https://en.wikipedia.org/wiki/File_system#Space_management

[nm]

Tiedostolla on tiedostojärjestelmässä minimikoko, joten paljon pieniä tiedostoja voi viedä enemmän tilaa kuin niissä on tietoa.
https://en.wikipedia.org/wiki/File_system#Space_management

Sekä df että du näyttävät kuitenkin oletuksena varattujen blokkien perusteella lasketun koon, eikä varsinaisen datan määrää:

Koodia: [Valitse]

# Kirjoitetaan yksi merkki tiedostoon
echo -n A > testfile

# Oletuksena du näyttää tiedoston koon kilotavuina (1 kB = 1024 tavua):
$ du testfile
4       testfile

# Tiedoston koko tavuina:
$ du -B1 testfile
4096    testfile

# Tallennetun tiedon määrä tavuina:
$ du -b testfile
1       testfile

En ole varma, mikä tässä Petterin tapauksessa selittää df:n ja du:n erot, mutta asia liittynee tiedostojärjestelmän sisäiseen kirjanpitoon. Df kaivaa informaation tiedostojärjestelmän superblokin kentistä ja du laskee yhteen tiedostojen ja hakemistojen koot käymällä ne kaikki läpi.

[petteriIII]

Tattista, tuo du:n kytkin -B1 antoi tuloksen: 46485504 jossa on enää se "1000/1024" ero gpartediin. Kytkin -BM poistaa tuonkin eron, mutta se ilmoittaa vain karkean arvon 45M.

- tein funktion tuosta sillä eihän tuommoista muista - tosin eipä käyttäjät enää ylläpidä omaa kirjastoaan ja yleistä ei ole. Funktion voi kuitenkin kopioida skriptiinsä. Funktiota kutsutaan: kansionkoko kansionnimi_polkuineen
- siis tuo 1000/1024 pitää ottaa huomioon kaksi kertaa

Koodia: [Valitse]

function kansionkoko () { echo $(du -B1 $1 | awk 'END{print $1}')*1000/1024*1000/1024 | bc ;};


[nm]

Tattista, tuo du:n kytkin -B1 antoi tuloksen: 46485504 jossa on enää se "1000/1024" ero gpartediin. Kytkin -BM poistaa tuonkin eron, mutta se ilmoittaa vain karkean arvon 45M.

Hmm. du:n pitäisi kyllä antaa sama tulos ilman mitään -B-vipuja, kunhan tulkitset lukuja oikein:

Koodia: [Valitse]

$ du -s -B1 Kuvat
1600741376      Kuvat/

$ du -s Kuvat/
1563224 Kuvat/

1563224*1024 = 1600741376

-s tarvitaan, jotta du laskee kokonaiskoon annetulle hakemistolle, eikä näytä alihakemistojen kokoja erikseen.


Jos tuloksen haluaa näyttää mebitavuina (1 MiB = 2^20 B = 1024*1024 B) tarkemmin kuin du, joka pyöristää kokonaislukuun, laskentaan voisi käyttää tällaista skriptiä:

Koodia: [Valitse]

du -s -B1 Kuvat | awk '{printf "%.2f", $1/(1024*1024)}'
Desimaalien määrää voi säätää tuolla %.2f -lausekkeella. Esimerkkitapauksessa tulos on 1526.59