ext4: tényleg olyan stabil?

 ( plt | 2017. szeptember 4., hétfő - 9:32 )

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?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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...

Az ordered az az arany középút a doksi szerint, azzal nem kéne beállnia.

Ennyire szétesett FS-nél jó eséllyel csak a külső fsck fog bármi eredményt hozni, de _mentésed_mindenképp_legyen_!

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 ()

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.

kernel parameternek egy init=/bin/bash
utana amugy is ro modban indul az ext3/4.

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

/lost+found ?

Oda szoktak elkúszni a "szabad" blokkok. És igen, miért ne csinálhatnál tartaléknak ro-mountos grub bejegyzést.

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

/lost+found mappa teljesen üres.

Ha a "du" paranccsal vegigjarod a mappaidat, hogy hol foglalodott le a 40GB? Valahol meg kell lennie.
Ha lusta vagy egyenkent nezegetni, ncdu esetleg.

Avagy a gyokerben "du -hs *", ami az adott konyvtarban levo osszes alkonyvtar es file meretet adja vissza.


Sic Transit Gloria Mundi

A gyökérben - vagy bárhol - kiadva a
du -hsx /
parancsot, 49GB-ot mutat. Sehol sincs lefoglalva a kérdéses 40-45GB! Pont ez a probléma!
S még a --apparent-size paraméterrel kiadva is ugyanez az eredmény.

Csak érdeklődésképpen. Hibás szektor nem csinál ilyet?

--
openSUSE 42.2 x86_64

Csinálhat gondolom, de azt az fsck-nak ki kellene szűrnie, a teljes ellenőrzés alatt. Amikor végigment a fájlrendszeren, helyre kellett volna igazítania a szabad terület méretét, kihagyva a hibás részeket, ha vannak.

Igen, azt tudom, hogy "kellett volna". Csak hát, ha mégse.

--
openSUSE 42.2 x86_64

ncdu ugyanazt az eredményt adja, mint a du.

É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.

A log mappa volt az első, amiből pucoltam. Jelenleg 39MB van benne.
apt-get clean lement, alapvetően nem segített, de jó ötlet volt (+1GB).
Attól tartok, hogyha valamilyen legális fájl mérete nőtt volna meg, akkor azt a du -hsx / kimutatta volna.

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

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.

azért csak ránéznék én arra egy `qemu-img info` -val meg egy `ls -lash` -val, hogy pontosan mi a helyzet. Bár ha jól emlkészem, ez inkább a másik irányba tud megszopatni.

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

Az img fájl szűzen is 33GB volt.
Valamint a 33GB-os fájl a du által 33GB-ként van beszámolva. Így jön ki a 49GB foglalt terület. Ezen felül hiányzik 40-45GB.

Részemről úgy gondolom, hogy Linux alatt nem kell újratelepítés mert az macerás. Csinálj egy mentést fs szinten + a boot szektorrol, majd formázd a host gépet és másolj vissza mindent.

Csak egy gondolat:

ls -ls --block-size=K


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

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?

Ahogy elnézem, spájzolni. De azt nagyon!

Például Btree directories, ezért sokkal gyorsabb fájl és mappa törlés mint ext3-on. Illetve sokkal nagyobb fájl méret korlát, dupla annyi mappa lehet, multiblock allocation, delayed allocation, journal checksum. fast fsck - elvileg egészében gyorsabb, ezt tapasztaltam is.

Áhá, a méretkorlátokról már hallottam, delayed allokálásról meg abszolút nem. Tulajdonképpen minimális tapasztalat, meg amit egyetemen tanultam.
Pontosabban már attól több. Köszi! :)

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.

Ez azért van, mert nem olvastad a blogomat! :P


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

Ez jó ötlet (+i flag mount pointra), grat :)

+1
Jo otlet

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?

Köszönöm, jó ötlet, ezentúl használni fogom.

Nem "df -h" -val kezdted egyből? :)

+1

Nálam az egyszerűség kedvéért minden mount point a /work, speciális esetben a /data alá kerül.
Ez a megoldás kizárja az ehhez hasonló hibákat. No, meg a kiesett diszk - ha nem tűnik fel - helyére sem lehet írni.

És akkor a /tmp egy symlink a /work/tmp-re, amely alá csatolva van egy tmpfs?


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

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.)

Szerintem hiába veszed el az írási jogot a root-tól, ő akkor is képes lesz írni. Legalább is Linuxon így van, s gondolom azért, hogy ne zárd ki magad. Jó, szívni persze lehet ilyesmivel:

chmod -x /bin/chmod

:)


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

Az meg kifejezetten csúnya, ha programok root-ként futnak.
Uff!

Ez igaz, de amikor egy valamilyen oknál fogva fel nem csatolt /var alá szemetelődik, azt root process-ek csinálják jellemzően. A kérdező épp ilyen pofonba szaladt bele.


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

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

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

PEBKAC ellen https://ko-fi.com/

Mire jó ez az oldal? Gondolom biztos nem arra hogy 1 dollárt gyűjtsön valaki. Az sem világos hogy milyen tartalom után. Össze tudnád foglalni? Érdekelne, köszi.

.