fsck likvidátor

[xmms]

Dnes jsem odprásknul celý linux.

S adresářem ~/.gvfs jsou standardní problémy již od instalace suse. Každou chvíli se sám poškodí (nevím sice proč) a je potřeba ho opravit pomocí fsck. Všímám si, že po každém dvacátém rebootování se fsck při startu automaticky spouští a opravuje chyby. A tak mi přišlo logické spustit init 1 a udělat to tam ručně. V init 1 toho moc neběží a snad by nemělo vadit, že je souborový systém připojený. Zadám

fsck.ext4 -y /dev/sda5

a katastrofa začala. Výsledkem je zničená celá struktura ext4 a můj nový filesystém vypadá asi takto:

Kód: [Vybrat]

#1717817
#1717820
#1717823
#1717826
#1717830
#1717833
#1717836
#1717839
#1717842
#1717846
#1717848
#1717851
#1717853
#1717856
#1717859
#1717862
#1717865
#1717868
#1717871
#1717873
#1717877
#1717879
#1717884
#1717887
#1717890
#1717893
#1717896
V těchto adresářích (cca 2500 kousků) jsou různě roztroušené soubory. Asi jsem měl provádět fsck z live media při odpojeném disku. Hmm, pozdě. Vím, že s připojeným diskem to nemusí dělat dobrotu (a že by se snad mohlo něco poškodit), ale fakt nechápu, proč to ten program musel takhle úplně celé zdevastovat. Prakticky nic použitelného mi na tom disku nezůstalo. Ve windows můžu opravovat disky za běhu a ničemu to nevadí.

Je pro tohle nějaké normální vysvětlení?

PS: jsem poslušný linuxák a poctivě zálohuju data. Ale stejně mě to štve.

[Reklama]

[eL]

Tohle me zajima. Me osobne fsck snad jeste nikdy nepomohlo, za to mi uz parkrat pekne zkomplikovalo zivot. Jake jsou zkusenosti?

[JardaP .]

To jste udelal celkem blbe. Priste si treba pomoci tune2fs -T nastavte, ze vas disk nebyl 10 let zkontrolovany a zrebootujte. Pokud to nezabere a bude to chtit nejake interaktivni zasahy, tak asi pouzit to live CD.

SuSE neznam, ale na Debianu ani na Eeebuntu se mi zadna data takto nemrsi a periodicky fsck pri bootu obvykle nerve. Mozna si pustte badblocks, otestujte pamet, zatahejte za kabely, vymette pavouky, pochytejte mysi a zkuste zatancit tanec Slunce. Mozna, ze vam strasi v HW.

[branchman2]

SuSE neznam, ale na Debianu ani na Eeebuntu se mi zadna data takto nemrsi

HW pravdepodobne nestrasi, dalsie fsck (najskor) nepomoze. Stalo sa mi to iste na Ubuntu/Debiane, spustil som fsck na primountovany ext3 disk a fsck presunulo skoro vsetko do /lost+found a dalo tomu presne take nazvy, ako pisal xmms. Dolezite data som si nasiel a vykopiroval. Clovek sa aspon nauci citat, ze sa fsck nema pouzivat na primountovany FS (tusim sa aj niekolkokrat pyta).
Kontroly pri boote s tymto nemaju nic spolocne, tie mi fungovali tiez dobre.

[branchman2]

Este som zabudol: ked nechces mat taketo problemy, skus si dat ReiserFS - ten sa este nepodarilo pokazit ani na PC s HW chybou - ext3 vydrzalo mesiac - potom uz len "bad superblock"; Windows po 2 tyzdnoch prestali bootovat s chybajucim NTLDR a Linux s ReiserFS sa drzi skoro 2 roky.

[Reklama]

[D.A. Tiger]

....snad by nemělo vadit, že je souborový systém připojený

Vadí. Kontrola disku (fcsk, badblocks, atd...) se provádí na nepřipojeném disku, a když experimentuješ s připojeným diskem, a nejsi si úplně jistý následky, tak by měl být disk připojen pouze pro čtení. 

[Kenji]

Já mám na SSD disku ext4 bez žurnálu na LVM a pokud mi neodejde další článek v baterce nebo jinak systém necrashne, tak nemám problém. Pokud crashne, tak vzhledem k tomu, že nemám žurnál .. au au.

ReiserFS je fajn FS, používal jsem ho poměrně dlouho. Ale i ten se mi podařilo docela hezky oddělat :-)

Jinak jak tak čtu odpovědi výše ... máte alespoň nahozený SMART pro monitoring disku? Nepřijde mi normální, aby FS odcházel prostě jentak, pokud je disk v pořádku.

[xmms]

To jsem kontroloval, disk je v pořádku. V HW nestraší. Podobnou zkušenost jsem měl i před pár lety, kdy jsem začínal s linuxem s fedorou. Tam jsem měl reiser a celé to odešlo, když mi vypli proud. Pak už jsem to mohl jen nainstalovat znova.

JardaP: to periodické řvaní fsck při startu je v pořádku. Někde je tam přednastavené, že se to má automaticky kontrolovat po každém dvacátém restartu. Což ale znamená, že to musí kontrolovat s připojeným oddílem (protože jak jinak by to dělal). No a když je to takhle nastavené z výroby, tak jsem logicky předpokládal, že to takhle můžu dělat ručně i já.

No a ten adresář gvfs dělá problémy neustále. To rozhodně není chyba mého HW, jen se koukněte do googlu a napište

.gvfs

google vám automaticky doplní

.gvfs is not accessible permission denied

A nějaký nalezený thread

Kód: [Vybrat]

When looking at it with an ls -l it looks like

????????????? ? ? ? ? ? .gvfs

I can not chown, touch, edit, remove, or do anything as the user of the home dir or as root. Both receive a permission denied.

Any suggestions?
Tento adresář se neustále pořád dokola poškozuje. Příslušný démon zřejmě obsahuje bug. Je toho plný google. Možná by bylo lepší tuhle věc vůbec nepoužívat.

Není tam nějaká možnost udělat fsck undo? Již za starých dob uměl scandisk ve windows uložit záznam o opravě na disketu, což by mělo umožnit vrátit akci zpět. Ale nikdy jsem toto nevyužil. No a v dnešní době moderních nadupaných souborových systémů jako ext4 bych to pokládal za samozřejmost.

[Tomáš Bžatek]

~/.gvfs je jen fuse mount, zadne poskozeni se nekona. Viz. vypis mount. Otazniky jsou tam proto, ze jsme zakazali cizim uzivatelum pristup, z bezpecnostnich duvodu. A to i rootovi. Root v dnesni dobe uz nic neznamena a nema absolutni pravomoce v systemu.

Viz. bug https://bugzilla.gnome.org/show_bug.cgi?id=560658

[x22]

Fsck pri starte sa robi s oddielom pripojenym read-only (to plati pre root, ostatne sa kontroluju nepripojene).

Na read-only pripojenom suborovom systeme fsck funguje, na read-write nie.

Ext4 na obycajnom diskovom oddieli nemoze poskodzovat nejaky user-space demon, jedine jadro alebo hardware. Ale ~/.gvfs/ nie je ext4, ale virtualny suborovy system Gnome. Tym padom s tym suborovy system na disku nema nic spolocne a fsck je zbytocny.

[covex]

1. nikdy fsck na rw systemu, kdyz uz tak ro.
2. gvfs neni poskozen, takoveto chovani adresare gvfs je zcela v poradku.
3. pokud nekomu pri pravidelnych kontrolach FS (jejich perioda se da nastvit) nachazi fsck chyby je spatne neco jineho, protoze pokud nedojde k vypadku proudu, resetu natvrdo atd. neni duvod aby nejake chyby vznikali a taky vetsinou nevznikaji.
4. pokud mam problemy s fsck tento ukoncim, provedu "dd" tzn. zalohu raw filesystemu a pak teprve laboruji s fsck y/n.

[xmms]

Tak jsem to nainstaloval znova a pracně jsem to znovu nakonfiguroval. Potřeboval bych udělat zálohu celého systému. Nechci ale provádět dd sda5, protože ten je o dost větší než soubory na disku, ale chci zkopírovat a zkomprimovat všechny soubory na disku do jednoho cílového souboru na externí disk. Udělat to pořádně, aby se mi nerozrasily simlinky, atributy, práva, vlastnictví apod. Abych mohl v případě potřeby vybalit archiv do kořene a mít rychle obnovený systém. Chci udělat nejrychlejší kompresi.

Napadá mě něco na způsob:

Kód: [Vybrat]

nabootovat live CD
mkdir /mujsystem
mount /dev/sda5 /mujsystem
tar cpzf /externidisk/mojezaloha.tgz /mujsystem/
a při obnově:

Kód: [Vybrat]

boot live
mkfs.ext4 /dev/sda5
mkdir /mujsystem
mount /dev/sda5 /mujsystem
tar xpzf /externidisk/mojezaloha.tgz -C /mujsystem/
Je to tak dobře? Co na to používáte vy?
A je lepší tgz nebo bz2? Jedná se mi o nejrychlejší kompresi, není nutné to za každou cenu smrsknout na minimální velikost.

Taky se bojím toho, že to bude se symlinkem zacházet jako s tím souborem a to není dobré.

Na netu jsem viděl nějaké návody jako třeba tohle

Kód: [Vybrat]

tar -cvpf /backups/fullbackup.tar --directory=/ --exclude=proc
--exclude=sys --exclude=dev/pts --exclude=backups .
A provádět to na běžícím systému. To mi přijde docela šílené a blbé.

[JardaP .]

gz je rychlejsi, nez bz2.

[alfi]

Co na to používáte vy?

mi se osvědčil rsync. běží pravidelně a po první delší kopii přetáhne vždycky jen pár změněných souborů a dá se spouštět i za chodu. nevýhodou je stejná velikost, jako původní systém.. výhodou zase funkční verze i na záložním médiu - nezkoušel jsem, ale mělo by z ní jít i nabootovat

[covex]

Zalohovani pomoci tar a gz je to nejbeznejsi a nelepsi co se da udelat. System ovsem nelze takto zazalohovat bezhlave, je potreba dat exclude na adresare proc, sys, dev a take samotny mount point kde je zaloha. Zaloh by se melo vzdy delat vic - aspon dve, protoze pri prepisovani vzdy stejne zalohy v okamziku kdy zalohy vytvarite zadnou zalohu nemate.
Zalohu pro co nejrychlejsi obnoveni neni ptoreba komprimovat pomoci gz ani bz2, samotny tar uz usetri dost mista.