Fórum Root.cz
Hlavní témata => Software => Téma založeno: xmms 05. 01. 2011, 07:46:54
-
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:
#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.
-
Tohle me zajima. Me osobne fsck snad jeste nikdy nepomohlo, za to mi uz parkrat pekne zkomplikovalo zivot. Jake jsou zkusenosti?
-
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.
-
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.
-
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.
-
....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í. ;)
-
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.
-
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
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.
-
~/.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
-
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.
-
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.
-
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:
nabootovat live CD
mkdir /mujsystem
mount /dev/sda5 /mujsystem
tar cpzf /externidisk/mojezaloha.tgz /mujsystem/
a při obnově:
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
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é.
-
gz je rychlejsi, nez bz2.
-
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
-
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.
-
přesně tak. A taky nezapomenout vynechat fuse mountpointy .gvfs !!!
-
Tak jsem to zálohoval jako tgz, ani to dlouho netrvalo. Z původních 5.5GB mám 2GB. Udělal jsem to z live CD a nemusím tak excludovat adresáře. Trochu jsem i experimentoval a bez adresářů dev proc sys ohlásí kernel panic, protože si je při startu sám nevytvoří, pokud chybí. Navíc i tyhle adresáře obsahují pár podadresářů, takže kvůli zachování struktury jsem je všechny ponechal. Je to čistší metoda, než to dělat za běžícího systému a excludovat.
Ale i tak mi to ohlásilo nějaké problémy:
linux:/moje # tar cvpzf /zaloha/zaloha_linux/system.tgz /moje > /zaloha/zaloha_linux/vystup.txt
tar: Removing leading `/' from member names
tar: /moje/var/run/sdp: socket ignored
tar: /moje/var/run/dbus/system_bus_socket: socket ignored
tar: /moje/var/run/acpid.socket: socket ignored
tar: /moje/var/spool/postfix/private/scache: socket ignored
tar: /moje/var/spool/postfix/private/bounce: socket ignored
tar: /moje/var/spool/postfix/private/uucp: socket ignored
tar: /moje/var/spool/postfix/private/anvil: socket ignored
tar: /moje/var/spool/postfix/private/verify: socket ignored
tar: /moje/var/spool/postfix/private/cyrus: socket ignored
tar: /moje/var/spool/postfix/private/proxymap: socket ignored
tar: /moje/var/spool/postfix/private/proxywrite: socket ignored
tar: /moje/var/spool/postfix/private/relay: socket ignored
tar: /moje/var/spool/postfix/private/bsmtp: socket ignored
tar: /moje/var/spool/postfix/private/lmtp: socket ignored
tar: /moje/var/spool/postfix/private/ifmail: socket ignored
tar: /moje/var/spool/postfix/private/rewrite: socket ignored
tar: /moje/var/spool/postfix/private/local: socket ignored
tar: /moje/var/spool/postfix/private/maildrop: socket ignored
tar: /moje/var/spool/postfix/private/retry: socket ignored
tar: /moje/var/spool/postfix/private/discard: socket ignored
tar: /moje/var/spool/postfix/private/error: socket ignored
tar: /moje/var/spool/postfix/private/trace: socket ignored
tar: /moje/var/spool/postfix/private/defer: socket ignored
tar: /moje/var/spool/postfix/private/virtual: socket ignored
tar: /moje/var/spool/postfix/private/procmail: socket ignored
tar: /moje/var/spool/postfix/private/smtp: socket ignored
tar: /moje/var/spool/postfix/public/cleanup: socket ignored
tar: /moje/var/spool/postfix/public/flush: socket ignored
tar: /moje/var/spool/postfix/public/showq: socket ignored
tar: Removing leading `/' from hard link targets
Jsou to nějaké sockety, které se mi do zálohy nezahrnuly. Proč? A co ten / hardlink?
Já bych si přál udělat kompletní zálohu se vším, aby to po obnovení bylo jako předtím.
-
Sockety se vytvari automaticky funkci bind() pri startu odpovidajici aplikace, takze je netreba zalohovat. Vlastne to poradne ani nejde.
Removing leading / je o tom, ze az to budete rozbalovat, pouziji se relativni cesty k mistu rozbaleni. Cili to budete moct rozbalit bokem a prohlednout/obnovit jen cast. Kdyby to tar neudelal, tak by se vam stalo, ze pri rozbaleni v /test by vam tar prepsal system. Ooops.
-
S tím socketem tomu moc nerozumím.
a) proč se tedy nesmazaly, když nejsou potřeba
b) na tom disku jsou uložené, takže by to nějak zkopírovat jít mělo, proč to nejde?
-
Zalohu pro co nejrychlejsi obnoveni neni ptoreba komprimovat pomoci gz ani bz2, samotny tar uz usetri dost mista.
A ako funguje to setrenie miesta tarom? Pokial viem, tak tar su len subory + informacie o nich.
-
A ako funguje to setrenie miesta tarom? Pokial viem, tak tar su len subory + informacie o nich.
Subory su do tar-u zapisane kontinualne, nie su zarovnavane na velkost bloku. Sice nepredstavuje vyraznu usporu proti niektorym filesystemom (napr. starucky ReiserFS), ale oproti ext2/3 ano.
-
Zkoušel jsem jen takový pokus. Vyrobil jsem nový ext4 /dev/sda9. Testoval jsem ho bez provedení změn, tedy
fsck.ext4 -nvf /dev/sda9Při odpojeném disku je vše OK, po připojení také, pokud jsem na něj ještě nic nezapisoval. Pokud tam vyrobím soubor,
třeba touch mujsoubor, fsck po dalším otestování na připojeném souborovém systému ohlásí chybu Počet volných iuzlů špatně. To znamená, že data se ještě nezapsala na disk. Zkusil jsem i syncnout pomocí SysRQ+s a znovu otestovat programem fsck. Výsledek stejný, pořád hlásí chyby. Teprve po umountování sda9 to otestuje bez chyb.
Dá se nějak pořádně donutit systém, aby tam flushnul všechno? Ani sysrq to zdá se neudělá.
Počet volných iuzlů špatně (48180, spočteno=48179).
Opravit? ne
/dev/sda9: ********** VAROVÁNÍ: Systém souborů má stále chyby **********