Partíció: foglalt+szabad<<méret

Fórumok

A rendszer Linux Mint 19.02 egy 500GB-os SSD-n.
Ez hogy lehet?


root@dejo-mint:~# df -Th
Fájlrendszer   Típ.     Méret Fogl. Szab. Fo.% Csatol. pont
udev           devtmpfs   12G     0   12G   0% /dev
tmpfs          tmpfs     2,4G  2,8M  2,4G   1% /run
/dev/sda1      ext4      458G  338G  7,7G  98% /
tmpfs          tmpfs      12G     0   12G   0% /dev/shm
tmpfs          tmpfs     5,0M  4,0K  5,0M   1% /run/lock
tmpfs          tmpfs      12G     0   12G   0% /sys/fs/cgroup
tmpfs          tmpfs     2,4G   24K  2,4G   1% /run/user/1000

338G+7,7G = 345,7G
A teljes méret = 458G
Hova tűnt 112.3G?

TimeShift sincs!

Hozzászólások

lsof deleted, swap, reserved, esetleg overmount.

A sok apró fájl. A 4K szektorba ha 1 bájtot írsz, akkor 4K-t elvesztesz a kapacitásból, miközben a foglaltság 1 bájt.
--
"Sose a gép a hülye."

Ez jól hangzik - de igaz-e?
Nyilván nem azt a részét vitatom, hogy az egyetlen byte tárolásához is a teljes allokációs egységet, mondjuk 4k-t le kell foglalni és hogy így igazábol 4097 byte nem használt, de lefoglalt.
Abban viszont közel biztos vagyok, hogy amikor a df parancsot kiadod, akkor az nem áll neki összeadogatni a fájlméreteket, hanem a szabad/foglalt terület nyilvántartásból indul ki - ennek megfelelően az 1 byte-os file-ra is 4k-t fog számolni, mint használt terület. És még igaza is van, mert fs szempontjából ez az 1 byte érdemi tartalommal rendelkező file biza 4k helyet foglal.
Csak ha ezt elfogadjuk, akkor a magyarázatod valójában nem magyarázza a problémát, mert a df esetén pont nem igaz.

ext4 nem bajtokban szamolja a szabad helyet, hanem blockokban. egy block meg lehet 4/8/16K, attol fuggoen hogy formaztad.
hogy az utolso blokkon belul hany bajt van azt mar mashol tarolja, de errol szep leirasok vannak a neten.
a df is ezt a total/szabad block mennyiseget mutatja (felszorozova a blokk merettel).

a du-nak is van kapcsoloja hogy a tenyleges vagy a lefoglalt fajl meretet akarod megtudni egy fajlhoz (man du)

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Első körben ezt: dumpe2fs -h /dev/sda1 . A -h fontos!

---------------------------------------------------------------
Csak akkor szólok hozzá egy témához, ha értelmét látom.

Köszönöm az eddigi tippeket, este megnézem, kipróbálom.
De ha vannak még ötletek, jöhetnek. :)
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Mondjuk külső rendszerrel indítva még nem vizsgáltam.
Egyelőre csak a "tune2fs -C 50"-el állítottam be az indítások számát 50-re és 24 indításonként végez a boot folyamán fájlrendszer ellenőrzést "tune2fs -c 24".
Újraindítás után sem változott a helyzet. De este megpróbálom egy Live rendszerrel is ellenőrizni.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

500GB != 500GiB
500GB-458GB = 42 GB csak.
458GB 10%-a ~ 45 GB 10% a root fenntartott terület, ha másként nem állítottad be.

Tudom és én a kérdésedre válaszoltam, lásd a fenti válaszomat.

Tudni kellene, hogy a gyártók SI szerinti mértékegységet használnak (GB) ami 10 hatványaira épül és nem az informatikai 1024 többszöröseit használják aminek a mértékegysége GiB.

Tudom ez egy fajta átverés, de ez van. Minden háttér tárolóra igaz!!

Neked csak az általam írt 10% hiányzik.

lsblk mit mutat?

Szerk, ignore, látom mi a gond csak a megoldást nem tudom :)

--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

Alapbeállítás 5% reserved, ha betelne a lemez tudjon még pld. a /var/log/ és a/var/mail/root alá írni az OS. Illetve fragmentáció miatt 95% fölött belassulhat az FS ha rengeteg az új file törlés és létrehozás.