EXT4 mi uz do baraku nesmie (diskuse)

[Jakub Lucký]

zkusil bych zkontrolovat paměti a vyzkoušet jiný hypervizor, popř. vyměnit IDE...

Btw: jaké bylo nastavení toho extu?

[deafboy]

V com to virtualizujes? EXT4 pouzivam roky a tvrdy shutdown nikdy nic nepokazil.

[Adolf Stalin]

JFS je odpoved na vsetky otazky ohladne Linuxovych FS... Mam na 200 pracovnych staniciach a na 60 serveroch a bez jedineho problemu - najvacsie RAID pole ma pri tom 1 PB...

[Vasilijevič Hitler]

Nevím jestli trololo, ale JFS používám už hooodně dlouho a k naprosté spokojenosti. Jedním z důvodů byly právě tvrdý vypnutí strojů.

[Adolf Stalin]

ja to myslim vazne, JFS je najodolnejsi a najspolahlivejsi FS pre Linux

[Jirka]

To můžu potvrdit, žádnej jinej fs u mě nepřežil tolik tvrdejch resetů, jako právě tenhle. Navíc efektivita ukládání souborů je vynikající, srovnatelná snad jen s FAT32 - než se do mě pustíte, myslím tím, kolik mi na disku zbyde volnýho místa, když tam nahraju určitý množství dat. Nedávno jsem to měřil.

[kralyk z abclinuxu]

Na předchozí komentáře bych aplikoval s/JFS/XFS/g; a můžu souhlasit

[lertimir]

To nemohu souhlasit. Několikrát se mi stalo, že při pádu systému (tvrdé power-off) při silné aktivitě XFS disku byly data nesmírně poničené. (velká aktivita znamená, že jsem zrovna kopiroval disk velké objemy řádu stovky GB a nekdy i velké počty - desitky až stovky tisíc souborů v několika paralelních proudech.). A pád byl pověšení systému v proprietálním grafickém driveru. Jednou i stará data nešla zachránit.

[gtz]

Bohužel XFS takové je ale jistě bude lepší než EXT4. Provozoval jsem ho na více serverech jak v R5/R6 tak i na obyčejných NASech a většinou se XFS z toho vždy otřepal.

[lertimir]

Může a nemusí být. Nedokážu tohle posoudit, protože na serverech mám vždy UPS a jestli se mi stalo v jednotkách případů, že server byl nedostupný přes SSH a nedalo se s ním nic dělat, tak to moc. (lépe řečeno z posledních 3-4 let si takový případ nepamatuji.) A v desktopu jsem si zvykl, že když provádím masívní diskové operace na XFS (používám jej stále pro disky pro velké soubory), tak neprovádím graficky problematické činnosti. Nicméně občas za dlouho se mi podaří vytuhnout stroj a root disk a /home disk mají ext4 a vždy se spolehlivě zotavily, i když na nich činnost probíhala.

Myslím, že tazatel hlavně má problém v tom, že odložený zápis má na dvou úrovních. Jednak v hostovaném FS má odložený zápis díky EXT4 (ale mohl by poladit charakteristiky pomocí tune2fs utility) a může mít ještě odložené zápisy jednak virtualizátorem a jednak hostitelským OS. Takže ve chvíli, kdy napřímo urve ten virtualizovaný stroj, může to být mnohem horší situace než když se urve napájení přímo na železe, protože ani to, co chtěl a zapsal EXT4 v hostovaném systému do svého virtuálného disku tam ve skutečnosti nemusí být.

[gtz]

To se mi stalo také, že uklízečka vysavačem nějak vykopla kabel od FC-Nasu. No naštěstí tam nebyl tak velký provoz. (vykopla kabel od FC do UPS

[jas]

Ja by som len podotkol, ze xfs dnes je dost ine nez xfs co i len rok-dva dozadu (xfs je dost intenzivne vyvijane) a prave v oblasti zotavenia po tvrdom pade sa odviedlo za poslednych par rokov velke mnozstvo prace.

[Sten]

Mám zkušenosti s rozpadlými RAIDy a XFS bylo jediné, co dopadlo nejhůř (nedalo se opravit a po ro mountu při čtení některých souborů a adresářů házelo kernel panic), ReiserFS ztratil jména asi čtvrtiny souborů a nedal se opravit (ale dal se mountnout ro a tak fungoval) a ext3 několik desítek souborů přesunulo do lost+found, ale po fsck dál fungovalo (byl to datový disk, takže nebylo potřeba dělat reinstalaci). RAID s JFS se mi nikdy nerozpadl, takže tam nevím.

[stativ]

Jen jestli to nemá na svědomí virtualizace, která nedělá sync kdy má. Typicky to byl problém hlavně s VirtualBoxem.

[Adolf Stalin]

To je blbost, virtualizace syncuje vtedy ked dostane pokyn od guesta. V synce a zapnutej write-cache pre disk v hoste by som hladal problem...

[trekker.dk]

... ne vždy je výchozí nastavení takové, aby se ten sync respektoval. Pak host může dostat potvrzení o dokončeném zápisu dřív, než hostitel skutečně zapíše data na disk.

[Adolf Stalin]

ale vacsinou zapisuje do suboru, preto pisem ze sync v gueste na to vplyv nema. Ak na to ma vplyv sync tak jedine v hoste a taktiez zapnuta write-cache a to takziez v hoste...

[pavlix]

Ak na to ma vplyv sync tak jedine v hoste

Tak jsem ten komentář taky pochopil.

[Heron]

To bohužel není pravda. VirtualBox nesyncuje ani když dostane pokyn. Odzkoušeno na aktuálním VirtualBoxu na W7 a virtuálním Debianem.

[Adolf Stalin]

Si si isty? Mne syncuje na pokyn guesta do suboru. To ci ten subor syncuje Windows host je ale otazka :D

[Heron]

Jsem. Tak jistě, ono to skoro vypadá, že VB ten soubor s diskem má otevřený jako normální soubor, bez O_DIRECT nebo podobného Win ekvivalentu. Takže tam funguje klasická write cachce, kterou VB nenechává ani flushnout.

[Adolf Stalin]

No do r*ti...

[stativ]

Bohužel mám podobnou zkušenost.

[Sten]

Pokud k takové situaci (tvrdý restart nebo kernel panic při zápisu) dojde, existují pro všechny souborové systémy tři možné následky:

1. Zůstane část nové verze
2. Nezůstane nic
3. Zůstane celá stará verze

Volte dle libosti, nakonec to jde i u ext4 pomocí parametru data

[tom]

Mel jsem stejnej problem a bylo to VirtualBoxem. IMO blbe syncuje. Po zmene na qemu bylo vse OK.

[msk]

Potvrdzujem, ze virtualizujem Virtualboxom. Trosku mi ale unika, preco by v tom mal mat prsty. Proste ked virtualna masina zdochne, tak zapisem na disk co mam v bufferoch a zavrem subor s virtualnym diskom. Pokial neumre aj hostitelsky system (w7), tak by sa to malo v poriadku zapisat, nie?

[Jakub Lucký]

No to právě není tak jisté...

[tom]

Moje domnenka je, ze kdyz udelate hardreset, tak to sestreli proces, ktery "emuluje" pocitac, takze prijdete o vse, co mel ten process v cache.

[stativ]

A protože VirtualBox řeší sync dost svérázným způsobem, tak je šance, že přijde i o to, co mělo být dávno zapsáno.

[tom]

To jsem napsal ve #14

[stativ]

A já už ve #4

[Thunder.m]

Musím potvrdit že mi Ext4 taky zlobil, ale stačilo pozměnit parametry při mountu a vše se vyřešilo, jinak byla velká šance že se při tvrdém resetu kompletně podělá FS, nejodolnější je hold ext2...

[pavlix]

nejodolnější je hold ext2...

Určitě?

[kralyk z abclinuxu]

Rozhodně ne

[gtz]

Na serverech raději vždy XFS, EXT4 mi taky párkrát padla, ale naštěstí to bylo jen na mašině na testy.

[xxxxxxxxxxx]

musím potvrdit, Ext4 se mě totálně rozsekala.

[ewew]

Zrejme rozhodnutie nechať ext3 systém bolo správne. Ďalšia otázka je či je dobré rozhodnutie deliť filesystém na jednotlive části.

[kralyk z abclinuxu]

Zrejme rozhodnutie nechať ext3 systém bolo správne.

Imho nebolo. Ext3 je v porovnání s modernějšími FS příšerně pomalé.

[krut]

Keby ste nepouzivali prijebany open source a linux mohli ste mat nadherny komercny zfs !

[ewew]

Are You trolling ? If the Answer is yes, then please leave this website. We are not interested in your opinion. We want to use and administer linux. Do you know what liberty is ? It is Freedom. Are free choice is linux, not because is free, but its something that we can modify without restrictions. We want to know how the system works. And linux software is better, because we can fix it. We dont need to wait for software maker to fix the bug. You can now find linux and its derivates in almost every device, server. I Think you like one click devices ? Do you like that your software vendor tells you what is good a what is bad .Linux is not in the way it was Ten Years in the Past.

Sorry za angličtinu. I keď podľa prekladača som to napísal skoro bez chyby.

[ewew]

Trolling detected ?

Yes

Check what to do if troll detected.

Found.

Dont continue in conversation.

End

[krut]

Co ti jebe ...ty budes rad ked fixnes o 10 rokov svoju anglictinu nie to kernel code. Tyzden googlis ako upgradenes debian a potom zajebavas internet kokotinami typu "LINUX JE NAJLEPSIII LEBO JE FREE"

GET A FUCKING LIFE

[Jakub Lucký]

GET A FUCKING LIFE

Thus sadth the troller of forums...

[ewew]

Choď sa venovať produktívnejšej činnosti na svojom super systéme o ktorý sa postará za teba firma. Jasne som ti napísal, že nás tvoj názor nezaujíma. Ak chceš trolovať tak choď trolovať na inú stránku, kde budeš mať svojích fanušikov. Odporúčam ti prečítať čo som napísal ešte raz. Lenže chceš trolovať, tak napíšeš aj to čo nie je pravda, len kvôli provokácii.

[pavlix]

Jako by tvé reakce byly nějak hodnotnější...

[stativ]

Chtělo by to nějakou metriku, jak hodnotný příspěvek do diskuze je. A na základě toho blokovat příspěvky. Takže by se nikdo nedozvěděl o tomhle geniálním a naprosto úžasném nápadu

[pavlix]

Tak tak. To by celý tenhle thread zmizel.

[ewew]

Uznávam, že som to mohol napísať bez použitia anglického jazyka. Aspoň mám dôvod prečo sa nič nepýtať v diskusii.

[mkmm]

get a life [urbandictionary.com]

[gtz]

No kdybych nebyl na linuxovém serveru tak bych Vám doporučil systém NTFS, ale ten jaksi není nativně podporován

[Honz]

A na co vlastně...?

[ewew]

Skúšal si vo VM rozdeliť filesystém na viacej časti ? Možné riešenie by bolo odkladať data na samostatnú particiu a po skopirovaní odpojiť odkladáci priestor. Iná možnosť je odkládať súbory do host systému.

[kolcon]

jestli to ext4 tam nemá nějaké slovenské špecifiká ;)

[msk]

Netusim, fyzicky sa to deje v Prahe :D.

[ivi]

nechapem mam ext4 uz od kedy bol v ubuntu a ziaden problem, nikdy, asi 20 strojov.

[frdrx]

To není filesystémem ale nastavením nebo něčím jiným.

[msk]

Ano, priznavam a priklanam svoj nazor k tomu, ze to bude skor tou virtualizaciou. Kazdopadne preventivne som to prehodil na jfs a dumam, co s tym dalej.

[frdrx]

Držím palce.

[msk]

Tu je to teda cierne na bielom, virtualbox ignoruje IDE/SATA flush command by default:

http://www.virtualbox.org/manual/ch12.html#idp56033840

[jyrki]

Dnes, tj. 29.9. mi havaroval disk s EXT4.
Jedna se o fyzicky stroj, notebook - nedoslo k zadnemu vypadku proudu a notebook jel ze site, baterie byla na 100%.
Uprostred prace mi zacali v Double Commanderu mizet slozky a spousteze z listy (prostredi Xfce).
Distro Linux Mint 15, jadro 3.8.0-30-generic.
extundelete cast souboru dokaze obnovit, testdisk take cast dat na disku vidi. Prosel jsem logy a jedine co jsem nasel, ze kratce pred tim nez se to stalo, mel problem s SD kartou, hlaska "FAT-fs (sdc1): error, invalid access to FAT (entry xxxxxxxxx)". Tato hlaska je v logu mnohokrat, nekolik desetitisicu zaznamu.
Disky s EXT4 na kterych se problem vyskytl jsou sda a sdb. Nechapu jakou to ma souvislost. Disky po hardware strance jedou bez problemu. Bohuzel jeden z tech dvou disku byl zalozni, prisel jsem tak o znacnou cast dat. Jedna z nejmene obnovitelnych slozek je fotoalbum.
Mimo testdisk, extundelete a ext4magic, napada nekoho jeste nejaky dobry tool na obnovu souboru z ext4?

[lertimir]

Jednak asi by byl vhodný nový dotaz a nepřikládat k již exiswtující protože tohle je nový problém. Ale váš dotaz vypadá, že vám na datech opravdu záleží, tak v žádném případě bych nedělal pokusy na těch discích přímo. V první fázi bych koupil nějaký externí disk a dd zkopíroval fyzicky ten (ty) porušené disky pomoci nějaké live distribuce jako systemrescueCD. K porušeným diskum bych přistupoval jako k externím datům a rozhodně nejel na nich systém a nejspíše pracoval hlavně z kopiemi.

Možnné recovery by také mohl dát PhotoRec

[ewew]

Súhlasím s skopirovaním obsahu diskov s poškodeným filesystémom a obnovou na inom systéme s prístupom na poškodené disky ako kópie original poškodených diskov.

[jyrki]

diky za odpoved a tip. PhotoRec urcite vyzkousim, nic jineho mi ani nezbude.
Doplnim ze data zmizela na dvou discich, kazdy mel 1TB, jeden interni a druhy externi. Ten interni byl rozdelen na 4 partitions:

hlavni system - ext4

druhy system - ext4

swap

data (home) - ext4

Druhy disk, mel jedinou partition ext4 s daty - backup
Zmizela vsechna data, napric vsemi partitions, jednoho jedineho uzivatele a to toho, ktery prave pracoval s tou SD kartou, ktera dle logu delala problem. Vklidu jsem dnes prosel ty logy znovu a peclive, posledni radek toho dlouheho vypisu o SD karte (32GB fs VFAT) rika, ze ta karta jiz neni pritomna, pote log konci a casove to odpovida chvili kdy zacli mizet data z disku. A dle toho co si vzpominam, vyprazdnoval se kos ktery mel mit 17 souboru.
Nicmene opravdu se mi zda divne proc by mela mizet data z hard disku, kdyz v tu chvili se pracovalo s SD kartou.

[gtz]

externí disk -> proč na ext4? Pokud tam byly fotky tak bych volil systém, který se dá všude přečíst. Já na jednom externím disku mám historicky XFS, protože jsou tam data které jsou použitá pouze na linuxu tak mi to tak zase tak nevadí.

Na ostatních externích zařízeních (fotky, analog video, konverze videí apod. ) mám vše formátované přes NTFS jen proto, abych to přečetl všude a v případě průseru mohl data bezpečně obnovit.

NTFS tam má i proto když potřebuji něco někam přenést a nevím zda dotačný používá linux a NTFS přečte skoro vše (už i chytré televize).

[jyrki]

vse co mi doma bezi, mi bezi na Linuxu. Nevidim duvod v homogennim Linux prostredi pouzivat nenativni souborovy system. Vzdy mam system oddelen od uzivatelskych dat a od roku 1997, kdy jsem s Linuxem zacal, resim problem s file systemem a obnovou dat poprve.

[gtz]

Bohužel u mne musím uvažovat nad rozdílným prostředím jak u sebe tak i u ostatních lidí s kterýma spolupracuji. Když jsem dělal pro nějakého známého převod z VHS tak jsem to stejně musel uložit někam na NTFS/VFAT box, protože většina chytrých televizí pobere akorát VFAT a novější sežerou už i NTFS. Linuxový disk sežere snad jen nějaké drahé DVB/S zařízení.

Většinou když jsem řešil nějaké věci kolem fotek (diapozitivy, úpravy) tak jsem to musel řešit na Windows. Už jen protože na Linux prostě nejsou drivery. Něco podobného je s převody VHS -> digitál, protože neexistuje moc nástrojů na pohodlný přenos VHS -> disk. Stejně Linux nepodporuje IEEE1394 master/slave zařízení na ukládání dat tak stejně jsem musel použít Windowsy. IEEE1394 boxy jsem používal protože se dají stohovat a 1394 bere méně cpu než USB.

Takže jsem vždy raději volil NTFS, sice drivery jsou obskurní/pomalé, ale z toho systému se dá obnovit skoro vše včetně názvů/adresářů.

Windowsy jsem používal převážně jen pro surové zpracování dat a vše ostatní jsem dělal už zase na Susáči.

[ewew]

Je rozdiel mať celý disk ako jednu particiu a viaceré particie. Mne sa raz podarilo zmazať svoj domovský priečinok na ext3. Keďže som včas prišiel na to, že je niečo v neporiadku, tak som odmountoval /home adresár. Toto môže spôsobiť problém pri prihlasovaní do GUI. To som vyriešil s tmpfs. Pomocou ext3grep sa podarilo obnoviť skoro všetky data. Z dôvodu, že som mal data na inom zdroji, tak som nakoniec nechal len nastavenia a skryté súbory a priečinky. Myslím, že zálohovať malé množstvá dát sa oplatí na DVD disky.

Sú tie disky v RAID alebo iné usporiadanie ? To vyzerá na nejaký bug, ktorý má nejaký divný spúštaci mechanizmus. Alebo je to iba náhoda.

[jyrki]

v RAID ty disky nejsou. Problem nenastal pri prihlasovani. Velke mnozstvi dat, az na fotky jsem mel zalohovane jeste na jinych discich (jsou zde jen dve Calc tabulky ktere nejsou v posledni verzi, coz me mrzi, ale nejak s tim mohu zit). Ale fotky potrebuju obnovit z puvodnich disku, ty nikde nemam a jedna se o stovky giga dat.

[ewew]

Myslím, že bude lepšie keď založiš otázku v poradni, pretože v komentároch blogu to môže byť problém nájsť. Po určitom počte nových blogov dôjde k skrytiu starších blogov.

[jyrki]

Uz to myslim nema smysl zakladat jako novou otazku, protoze pomoci photorec jsem vetsinu dat obnovil.

[gtz]

photorec neobnoví názvy .. pro ext4 neexistuje moc utilit, které dokáží udělat data minning. Ty tools jsou jen pro Widle a jsou kurewsky drahé.

[jyrki]

Tak prvni partition jsem nechal byt, ta data jsem mel temer 100% zalohovana jeste jinde. Na externi disk jsem pouzil photorec a mam obnovenych cca pul milionu souboru. Je dobre ze to alespon dava prilohu a ve vetsine pripadu obnovil datum souboru. Takze fotky se daji rozhazet podle datumu...jeste nevim jak velke mnozstvi dat jsem zachranil, ale zda se ze vetsinu. To ze neobnovil nazvy souboru je celkem jedno. Diky za tipy nejen gtz, ale vsem kdo se snazili poradit.

[gtz]

Pokud se zachoval exif tak by to šlo celkem elegantně a hromadně přejmenovat.

Bohužel ext4 i XFS jsou celkem stabilní a robustné systémy, ale pokud se něco poláme nebo náhodou i něco smaže pak je s tím kupa práce dostat aspoň nějaká data.

[jyrki]

bohuzel exif v tech fotkach nezustal. Z kazde fotky mam tri soubory, fotka, nahled a textak s exif informacemi. Pri tom kvantu fotek neni v mych silach to obnovit manualne a strojove me nic nenapada...

[gtz]

Divné, já když jsem o prázdninách obnovoval soubory z CF karty tak fotky zachránil všechny (i ty předtím smazané) a fotkám zůstal exif.

Pokud jsou fotky poškozené tak doporučuji na prohlížení XnView. S ním mám celkem slušné zkušenosti, že otevře i hodně poškozený obrázek.

Já jsem zkoušel používat na obnovu jak Photorec tak i Foremost i MagicRescue. Popř. šel použít i recoverjpeg.

[jyrki]

poskozene nejsou, vsechny fotky jsou naprosto v pohode, jen nemaji EXIF...

[lertimir]

Ty fotky jsou rawy? není EXIF v těch náhledech? tam by mohl být nejen exif náhledu ale i RAWu. (který foták dělá fotky do třech souborů?

[gtz]

Už jsem to zde sem psal, tyto tooly jako jsou testdisk nebo photorec zachrání data fotky apod.. ale NEULOŽǏ je do původních adresářů a s původními názvy. Bohužel pro Linux neexistují sofistikované nástroje pro data minning/recovery apod. tak, aby se dalo cokoliv jak-koliv zachránit. Bohužel. Tyto nástroje existují jen pro Windows based systémy a není to levná věc.

Doporučuji použít dd_rescue popř. dd-čkem si udělat backup surového disku někam na jiný disk, aby se dalo experimentovat.