Dotaz: !!Akutní - Chyba při mountování oddílu

[exilim]

Zdravim, mam ubuntu 9.04 a přes LVM propojené 2 pevné disky.
Dneska při pokusu o namountování mi to vyhodilo tuhle chybu:

root@delta:/# mount /dev/data/disk0 /mnt/disk
mount: chybný typ SS, chybný přepínač, chybný superblok na /dev/mapper/data-disk0,
chybí kódová stránka nebo pomocný program nebo jiná chyba
V jistých případech lze najít potřebné informace v systémovém
protokolu – zkuste například „dmesg | tail“

root@delta:/# dmesg | tail
[ 1676.640945] JBD: recovery failed
[ 1676.640948] EXT3-fs: error loading journal.
[ 1676.648056] sd 2:0:0:0: [sdb] 1953525168 512-byte hardware sectors (1000205 MB)
[ 1676.651482] sd 2:0:0:0: [sdb] Write Protect is off
[ 1676.651490] sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 1676.651873] sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 1676.652212] sd 2:0:0:0: [sdb] 1953525168 512-byte hardware sectors (1000205 MB)
[ 1676.652388] sd 2:0:0:0: [sdb] Write Protect is off
[ 1676.652392] sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 1676.652628] sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

Nějak nechápu co se stalo, může mi někdo pomoct prosím? Jde mi o 1,5TB dokumentů (Fotky, videa, eshopy, RS, ...)

 

Díky moc za každou radu už sem vážně zoufalej :o(

Odpovědi

[wike]

Z Ubuntu Forums:

sudo debugfs -w -R "feature ^needs_recovery" /dev/sda1 # remove the needs_recovery flag
sudo tune2fs -O ^has_journal /dev/sda1 # remove the journal

sudo fsck -v /dev/sda1 # check/repair the filesystem
sudo tune2fs -j /dev/sda1 # Add an ext3 journal to sda1

Pripadne este How to recover an ext3 volume with an unreadable journal

[exilim]

Bohužel zasekl jsem se hned u prvníh příkazu :o((

 

bosss@delta:~$ sudo debugfs -w -R "feature ^needs_recovery" /dev/sdb1
debugfs 1.41.3 (12-Oct-2008)
/dev/sdb1: Bad magic number in super-block while opening filesystem
feature: Filesystem not open

[stativ]

Pokud je to poškozeným superblokem tak máš štěstí, že tam je EXT3, ten si totiž superblok zálohuje. Jak zálohu superbloku najít a systém opravit máš krásně popsáno na nixCraftu.

[exilim]

A je tam ext3 na 100%? já jen že to je přes LVM ten si dělá svoje fatky ne?

[exilim]

root@delta:/home/bosss# dumpe2fs /dev/sdb1 | grep superblock
dumpe2fs 1.41.3 (12-Oct-2008)
dumpe2fs: Bad magic number in super-block pĹi pokusu otevĹĂ­t /dev/sdb1
root@delta:/home/bosss#



:o(((

[JMP]

neni ve Vasem pripade relevantni spis /dev/data/disk0 nez /dev/sdb1?

[exilim]

mysel sem ze je chyba na disku a né v LVM? LVM si vlastně vytvoří svoje fatky, ale proč to teda ází chyb jen u sdb a né i u sdc???

[iji]

Urcite se podivat na pvdisplay a vgdisplay, ktere daji odpoved na LVM

[exilim]

root@delta:/home/bosss# pvdisplay
--- Physical volume ---
PV Name               /dev/sdb1
VG Name               data
PV Size               931,51 GB / not usable 3,19 MB
Allocatable           yes (but full)
PE Size (KByte)       4096
Total PE              238466
Free PE               0
Allocated PE          238466
PV UUID               1CA7t9-hhs3-vgv1-db6u-wD7S-UXfq-yHBPBj

--- Physical volume ---
PV Name               /dev/sdc5
VG Name               data
PV Size               149,04 GB / not usable 1,47 MB
Allocatable           yes
PE Size (KByte)       4096
Total PE              38154
Free PE               2700
Allocated PE          35454
PV UUID               V6ryeA-kZCX-Sxx3-ar6G-16ct-5HHL-zUXpWr

 

root@delta:/home/bosss# lvdisplay
--- Logical volume ---
LV Name                /dev/data/disk0
VG Name                data
LV UUID                0SIz8E-aDnV-7hLL-S15T-0003-I31c-qRpmmp
LV Write Access        read/write
LV Status              available
# open                 0
LV Size                1,04 TB
Current LE             273920
Segments               2
Allocation             inherit
Read ahead sectors     auto
- currently set to     256
Block device           254:0

[JMP]

pokud hledate hw chyby hdd, pak je prace primo s diskem v poradku (badblocks a pod.) nebo hledate chyby sw (nekonzistence fs), pak je treba myslet na to, ze tento konkretni fs je u Vas nad lvm a lvm je nad diskem/disky...

nicmene - bez toho, ze situaci popisete konkretneji, jen tak nikdo neporadi...

[exilim]

Tak pokusim se vypsat znova.

 

Přes LVM mám spojené dva oddíly (sdb1 a sdc5) a mám je propojený jako "jeden disk" doromady prostě /dev/disk/data0 maj asi 1,3TB.

 

Když sem chtěl nedávno namountovat, hodilo mi to chybu viz příspěvek uplně nahoře... Už se v tom začínám ztrácet, půlka lidí mi tu říká že je nemocnej jurnal a druhá půlka zas že je špatnej superblok ....

[JMP]

/dev/data/disk0 - to je cil pro kontrolu integrity fs

nicmene si projdete dmesg cely (tail vypsal jen konec, ale tomu budou imho predchazet hw problemy disku...)

pokud je to hw problem, tak jej stejne musite vyresit jako prvni, jinak se z problemu nevyhrabete (to je chvile, kdy se obvykle ukaze, ze neni zaloha...)

[exilim]

ok hned to sem postnu

 

root@delta:/home/bosss# dumpe2fs /dev/data/disk0 | grep superblock
dumpe2fs 1.41.3 (12-Oct-2008)

 

dumpe mi zadne alternativni superbloky nevypise :(

[exilim]

cely dmsg: http://temp.centrumpc.net/putty.log

[JMP]

mam pocit, ze je to hw problem - asi Vam odchazi ten 1TB disk, takze nejprve musite poresit hw...

pokud nemate zalohy, tak by asi bylo nejlepsi vzit stejny disk a pomoci ddrescue na nej zkusit prekopirovat co pujde

pak ten chybujici vyndat, dat misto nej ten novy a o pripadnou zachranu filesystemu se pokouset az na nem

nicmene s takovymto postupem nemam realne zkusenosti, tak bude lepsi pockat, az se k tomu vyjadri nekdo zkusenejsi

[exilim]

HW chybny to asi je blbost, ten disk je pul roku stary a bezel dohromday max 60hodin, tohle se stalo kdyz vypadl proud (na disk se ani nezapisovalo ani necetlo)

[JMP]

ja si myslim, ze to je hw problem a ze Vase data jsou timto v ohrozeni...

o spolehlivosti dnesnich disku jsem pramalo presvedcen (a je uplne jedno, ktere znacky...)

[stativ]

Právě nové disky odcházejí nejčastěji.

[wike]

Vas problem je asi v tom, ze disk nefunguje ako by mal.

[13104.880555] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[13104.880566] ata3.00: BMDMA stat 0x4
[13104.880575] ata3.00: cmd 25/00:f8:07:bc:1c/00:00:3a:00:00/e0 tag 0 dma 126976 in
[13104.880576]          res 51/40:00:cd:bc:1c/40:00:3a:00:00/e0 Emask 0x9 (media error)
[13104.880581] ata3.00: status: { DRDY ERR }
[13104.880583] ata3.00: error: { UNC }
[13104.905344] ata3.00: configured for UDMA/133
[13104.905371] ata3: EH complete
...
[13120.957685] ata3.00: status: { DRDY ERR }
[13120.957688] ata3.00: error: { UNC }
[13120.981392] ata3.00: configured for UDMA/133
[13120.981460] sd 2:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[13120.981465] sd 2:0:0:0: [sdb] Sense Key : Medium Error [current] [descriptor]
[13120.981471] Descriptor sense data with sense descriptors (in hex):
[13120.981474]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[13120.981482]         3a 1c bc cd 
[13120.981486] sd 2:0:0:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed
[13120.981493] end_request: I/O error, dev sdb, sector 974961869
[13120.981520] ata3: EH complete
[13120.981606] JBD: Failed to read block at offset 5464
[13120.981617] JBD: recovery failed
[13120.981620] EXT3-fs: error loading journal.
[13120.984043] sd 2:0:0:0: [sdb] 1953525168 512-byte hardware sectors (1000205 MB)
[13120.988079] sd 2:0:0:0: [sdb] Write Protect is off
[13120.988086] sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[13120.990153] sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[13120.992290] sd 2:0:0:0: [sdb] 1953525168 512-byte hardware sectors (1000205 MB)
[13120.993044] sd 2:0:0:0: [sdb] Write Protect is off
[13120.993050] sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[13120.994160] sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[20495.900761] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[20495.900771] ata3.00: BMDMA stat 0x4
[20495.900779] ata3.00: cmd 25/00:00:a0:d9:1c/00:02:3a:00:00/e0 tag 0 dma 262144 in

[David Watzke]

Podobný chyby podle mých zkušeností může způsobovat i řadič, i když v tomhle případě je asi disk pravděpodobnější.

[exilim]

řadič je přídavnej přes PCI

[MMichal]

Mě podobnou chybu (bohužel detail si již nepamatuju) způsoboval právě řadič - eSATA II Express Card v notebooku. Řešením nakonec bylo poštelovat parametry SATA, konkrétně v mém případě snížit rychlost z 3 Gbps na 1.5 Gbps. Doporučuji vyzkoušet připojit disk přes USB (mě to tehdy fungovalo právě přes USB a přes eSATA nikoliv).

[exilim]

Nemohu měnit připojení ty dva disky sou na sobě závislý

[MMichal]

To ale na 99% nevadí. LVM sestavuje VG na základě UUID jednotlivých PV, nezávisle na umístění.

Nicméně pro všechny případy bych rozhodně provedl zálohu dd-čkem.

[exilim]

ok a jak to funguje? nikdy sem to nedelal a jeste budu muset sehnat disky

[MMichal]

Jak nekdo radil vyse, pouzijte ddrescue, ktery narozdil od obycejneho dd pri chybe pokracuje dal. Nastroje dd, ddrescue kopiruji data 1:1 z jednoho blokoveho zarizeni nebo souboru na jiny. Timto muzete napr. zkopirovat cely disk/partition/LV/ do souboru na jinem zarizeni. Vice jiste napovi manualova stranka k dd, ddrescue, dd_rescue.

[exilim]

a dás e to tahat třeba po určitejch souborech?

[MMichal]

Ne, tohle kopiruje cele (resp. lze urcit pocatek a mnozstvi) blokove zarizeni nebo soubor po blocich. Soubory jsou zalezitosti souboroveho systemu - na to je nutne souborovy system pripojit a kopirovat po souborech.

[Ash]

nedá, dd neví nic o fs a souborech. Chtěl jste jednu velkou logickou hromadu dat (LVM), máte ji :(

[Sinuhet]

Libata error messages