ext4: tényleg olyan stabil?

Debian GNU/Linux

Az irodában egy Debian 8-as ext4 fájlrendszerű folyamatosan üzemelő gép ma reggel áramszünetet kapott.
Bekapcsolás után észrevettem, hogy a root partíció tárterülete megtelt. Általában sok 10 GB szabad hely van rajta.
Töröltem 6GB adatot, amire azt jelzi, hogy 106GB-ból 100GB foglalt, szabad 0.
További erőlködéssel még 140MB területet tudtam felszabadítani, most van 140MB szabad terület a meghajtón.A du -hsx / parancs szerint a meghajtón 55GB foglalt hely van.
Sebaj - gondoltam -, majd egy fájlrendszerellenőrzés helyre teszi, bár a journalnak ezt el kellett volna végeznie. 

shutdown -rF now

Semmi.
Továbbra is 100GB foglalt, 140MB szabad.
Kézzel is létrehoztam a /forcefsck fájlt, majd reboot. Ugyanez.
Próbáltam recovery módban bootloni, de nem engedi ro módban remountolni a root partíciót, mivel busy.
init 1 után ugyanez a helyzet.
Egyrészt ez picit ellentmondani látszik annak, hogy az ext4 annyira stabil lenne, másrészt meg mit csináljak, hogy visszanyerjem a 40GB szabad területemet, vagy hogyan találjam meg a szemetet?

  • 2997 megtekintés

( Szenti v | 2017. 09. 04., h – 09:56 )

Nem hiszem, hogy egyetlen - elszigeteltnek tűnő - esetből helyes olyan messzemenő következtetést levonni, hogy az ext4 nem stabil. Az EXT4 nem szokott egy áramszünettől lehalni. Próbáld meg egy LiveCD-ről (Pl.: Finnix, vagy SystemRescueCD) bebootolni a gépet, és arról fsck-zni a fájlrendszert. Előtte persze nem árt, ha van mentésed.

Memóriahiba is okozhat problémát, egy éjszakára ráengednék egy Memtest-et a gépre.

+1 Azt mindenképp érdemes lenne megnézned, hogy mennyire volt az a journal journal. Egy ideje ordered az alap mount option és nem a leggyengébb writeback, de ha nincs UPS, akkor egy fullos journal opció nem árt. A fenti problémától függetlenül én javaslok egy egyszerű szünetmentest. A fő indok mellette, hogy a hirtelen és rövid áramszünetek ellen véd és ha hosszabb van, akkor szépen lekapcsol. Természetesen a túlfesz/túláram védelemről se feledkezzünk meg.

Abban biztos vagy, hogy nem több rövid áramszünet "darálta le" a filerendszered? Ha pl. automatikusan visszaindul a géped áramszünet után és boot közben megint elmegy a kraft és ez ismétlődik abból már bármi lehet.

Tudom, hogy az ext4 nem szokott ilyeneket csinálni, ezért is lep - vagy ijeszt - meg ez az eset.
Van szünetmentes, de sajnos nem tudtam még elérni, hogy lemerülés előtt leállítsa a gépet. Kb. 15 percig tudja életben tartani, aztán leáll. Utána nem indul el automatikusan, tehát nem darálta le. A fájlrendszer opciókban data=ordered van. Ezek szerint ez gáz?
Lehet, hogy memória, lehet, hogy ext4 bug vagy csak gyenge naplózás(?). Az elsődleges most az lenne, hogy egy teljes fájlrendszerellenőrzést ki tudjak erőszakolni. Végső esetben kívülről fogok bootolni, de most szeretném megtudni, mi a teendő, ha távoli ext4 esetén történik ilyen.
Ha meglesz a hiba oka, talán az ext4 is mentesül a vád alól...

Nem kritikus a rendszer, és mentés is van, bár az újratelepítést még halogatnám.
Amúgy nem esett szét. Minden stabilan megy. Azóta további 3GB területet tudtam felszabadítani. Olyan, mintha az a 40GB valóban lenne valahol, csak nem tudom hol.
Lehet, hogy a grub-ban létre lehetne hozni egy olyan indítási opciót, amivel ro módban csatolja fel a fájlrendszert?

Én ilyenkor a recovery módban a root shell-t kiválasztom, majd mount -o remount,ro / és utána egy e2fsck -fvyD /dev/"valami" szoktam futtatni. Ha nincs memhiba, ez rendbe tette eddig nálam.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

Én is így emlékeztem, hogy ez lenne a teendő, de azt mondja, a device busy. Nem lehet remountolni.
Érdekes módon, ha létrehozom a /forcefsck fájlt, az újraindítás után eltűnik, mégis, a 


tune2fs -l /dev/sda1

ezt írja ki utána: 


Filesystem created:       Fri Mar 25 10:05:01 2016
Last mount time:          Mon Sep  4 11:10:30 2017
Last write time:          Mon Sep  4 11:10:29 2017
Last checked:             Fri Mar 25 10:05:01 2016
Check interval:           0 (<none>)

Azaz nem történt ellenőrzés. (Talán ugyanabból az okból, ami miatt init 1 módban nem lehet csak olvashatóan reountolni.)

Na várjál. A recovery root shell-je, és a grubban átállított init 1 nem ugyan az. Te melyiket használod.
Illetve a helyedben alaposan áttanulmányoznám a (bocsánat) dumpe2fs -h /dev/sda1 -et.

Ezt a device busy dolgot már nekem is produkálta párszor. Nem jöttem rá hogy mi okozza.

Illetve van egy overkill (kicsit körülményes összehozni) megoldás, ha egy letöltött rescue iso-t indítasz a grubból.
Még soha nem csináltam, de távolról működhet.

Szerk: látom sikerült valamit haladnod. Akkor az utókornak.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

init 1 után leállítottam minden futó programot, és így már sikerült ro módban újracsatolnom a root partíciót! :)
Lefuttattam az e2fsck -fvyD /dev/sda1 parancsot, végig is ment, javított is. Végre a tune2fs is jelzi, hogy lefutott az ellenőrzés. Ennek ellenére jelenleg a foglalt terület 95GB, mígy a du -hsx / parancs szerint csak 49GB.
40-45GB továbbra is hiányzik!
:O

( szilas | 2017. 09. 04., h – 11:16 )

Én a helyedben az /var/log könyvtárat megnézném, nem hízott-e meg valamelyik log. Ez egyébként egy kritikus hiba miatt is lehet.
Illetve biztos ami biztos alapon, nyomj egy apt-get clean-t is. Plusz ha már ott vagy, nézz rá, hány kerneled van. A régieket lehet törölni. Header-rel együtt.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

( lajos22 | 2017. 09. 04., h – 11:29 )

Na ilyen még nem történt. Feliratkozom!
--
openSUSE 42.1 x86_64

( locsemege v | 2017. 09. 04., h – 13:01 )

Vannak nagy file-ok, például virtuális gép image azon az fs-en? Azon gondolkodom, nem lehet-e az, hogy sparse file-ok kibontásra kerültek netán. Tehát van a file-ban néhány gigabyte-nyi nulla, amit bejegyzett, hogy ide kell képzelni néhány gigabyte-nyi nullát, de ez ténylegesen alig pár byte, viszont, ha hivatkozol rá, visszaad néhány gigabyte-nyi nullát röptében, mert ez a dolga. Ha ez kifejtődik tényleges tárhelyre, akkor eltűnik néhány gigabyte.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ez jó gondolat. Egy nagy virtuális meghajtó van: 33GB. Ez egy qemu raw img formátum, tehát egy 33GB-os meghajtó. Ez ennyi, nem tud több lenni. Ezen kívül egy kis 4GB-os teszt virtuális gép futott még, de annak a meghajtója már nem a root partíción volt.
Összességében tehát félek, ez sem a jó megoldás.
Azóta a programok által linkelt, de fájlrendszerben nem szereplő fájlokra is rákerestem (lsof +L1), de ez sem az.
Rákerestem azon fájlokra, ahol az inode szám 0. Ez azóta fut. (Leáll valaha is?) Azonban ez sem találja a szemetet.

Több nem tud lenni, de eredendően kevesebb igen. Tehát az lehet, hogy összeadod a lefoglalt blokkokat, ezt megszorzod a blokkmérettel, s ez nagyobb szám lesz, mint a filerendszer mérete. Azért, mert a sparse file fizikailag kis helyet foglal, legalább is addig, amíg egybefüggő nagy részeken nullák vannak. Viszont, ha valaki el akarja érni azt a területet, akkor a kernel visszaadja a nullákat, de nem háttértárról olvasva, hanem aktuálisan generálva.

Arra utaltam, hogy mi van akkor, ha a szabálytalan leállást követően a filesystem check egész egyszerűen elkezdte ténylegesen kiírni ezt a 33 GB-os image-et a diszkre, s közben megtelt a lemez. Mert az egy dolog, hogy 33 GB-os az a file, de ha sparse, akkor eredendően nagyon kicsi, miután telepítettél bele valamit, akkor sem sokkal nagyobb, mint azon blokkok, amelyek már nem nullát tartalmaznak. Tehát például foglalt 2 GB-ot a 33 GB-os file. Az fsck után meg 33 GB-ot, s így eltűnt 31 GB. Ez csak példa, s tudom, nem stimmelnek a számok, mert neked több tűnt el. Mindegy, csak egy gondolat volt, hátha érdemes ezen a nyomon elindulni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( winben | 2017. 09. 04., h – 13:16 )

Azt tudom, hogy az ext2 előnye az, hogy nem naplózik, ezért gyors, cserében a (postban említett) leállás problémát okoz, vagy legalábbis végig kell nézni a lemezt.
Az ext3 lassabb a naplózás miatt, de gyorsabb a vizsgálat indításkor (nem kell a node-tól eof-ig végigkeresni a teljes láncot)

Namost mit tud az ext4?

( plt | 2017. 09. 04., h – 15:05 )

Köszönöm mindenkinek az ötleteket, megvan a megoldás.
Továbbra is bízhatunk az ext4 fájlrendszerben, bár nem tudom, milyen eszközzel lehetett volna megtalálni ezt a hibát.
A gond az volt, hogy egy felcsatolt meghajtó egyszer nem csatolódhatott fel, így a csatlakozási mappájába kerültek fájlok, amiket a most sikeresen felcsatolt meghajtó elfedett.
Számomra a tanulság: -x paraméter helyett umount minden egyéb eszközre.

Hogy ezzel én anno hogy megszívtam anno a DEC / Compaq egyik oktatótermi szerverén. Ott a /tmp nem mountolódott fel, mert az egyik kedves nebuló berakta az fstab megfelelő sorába, hogy az FSCK-Pass-No 0 legyen. És az első szabálytalan leállítás után máris nem volt önálló tmp, a rootFS meg csak fogyott, fogyott. (Tru64-en meg ugye nincs chatr +i :-) )

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Valójában a / is a /work alá van mountolva symlink nélkül. :-D

Az ötlet olyan ipari rendszerből indult ki, ahol nincs meg a választás szabadsága. ;)
Ezzel szemben van egy biztosan működő oprendszered.
Először. Utána lehet mountolgatni.
Az oprendszer mentésekor az exclude listában szerepelhetnek mindazok a vg-k és fs-ek, amik a gépen futó rendszerek működéséhez szükségesek, és általában az általános /work és /data mountpointok alatt csücsülnek.
A /tmp-vel történő variálás már csak azért is ostobaság, mert az általában minden rendszeren az operációs rendszer része.

Kivételt képez egy bizonyos IBM szervizes srác, aki a 2x2GB diszket tartalmazó gépet +4GB diszkkel bővítette. Hogy ne legyen vele munkánk, rögtön fel is mountolta /tmp-ként, mert annak úgy is nagynak kell lennie. ;-) (Segítek: Nem.)

Valójában a / is a /work alá van mountolva symlink nélkül.

Ezt nem értem. A / attól rootfs, mert a kernel őt kapja meg paraméterként, s bármit ez alá lehet csatolni. Vagy úgy érted, hogy egy bind mount-tal a /work alá csatoltad a /-t is?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

:)
Nem. Ezt úgy értem, hogy hülye kérdésre hülye válasz.

Elképzelésem szerint először elindul az oprendszer, majd utána jönnek az egyebek. Legalábbis így szoktam meg.

Kíváncsiságból megnéztem a feljebb idézett blogodat. Nem szép, ha a reserfs3+ és linux specifikus dolgokat használsz. Próbáld ki a következőt (legyen a példa a /work): 


umount /work
chmod 500 /work # dr-x------  2 root  wheel  512 Aug 27 01:17 /work
mount /work     # drwxr-xr-x 10 root  wheel  512 Sep  3 12:07 /work

Funkcionálisan ugyanazt csinálja. (Ez egy FreeBSD rendszer.)

Vettem. ;)
Ebben az esetben az oprendszer indulása a hibás. Nyilvánvalóan van valamilyen rc (bárhogy is hívják), amely az oprendszer "kellékeit" indítja el. Ebben meg van egy olyan mount parancs, aminek az eredményét nem ellenőrizte senki. Hívhatod pofonnak is, de inkább valami nagyértékű irodalmi műben van a helyes megfogalmazás: SzbSzk rendszer==Szemét be, szemét ki.

Tisztában vagyok vele, hogy az én immutable flag-es megoldásom egyfajta workaround, s nem oki kezelés. Semmivel sem jobb, mint influenzára a lázcsillapító. :) De legalább nem szalad tele a rootfs, nem történik az, ami a kérdező esetében, aztán keresi, hol a fenében vannak az eltűnt byte-ok, de nehéz kiszúrni, mert a tetejére csatolt filerendszer jól elfedi azt.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( wachag | 2017. 09. 05., k – 08:50 )

Ezek szerint nem, a PEBKAC ellen nem véd ;-)