Avui me n’ha passada una de curiosa que amb els meus bastant limitats coneixements de filesystems (i més concretament del ext3) no sé explicar:
Tenia un disc (bé, el disc encara el tenc, el que em falta és lo important: el contingut) amb una sòla partició amb un filesystem ext3.
Per motius que no venen al cas, aquest disc ha patit moltes penjades del sistema que l’hospedava (problemes de hardware). Moltes. Total que finalment avui l’he acabat sustituint a aquest sistema per un de més adient.
Per a treure’n el contingut l’he posat a una caixa usb d’aquestes externes de 3.5″. En muntar-lo (sense cap problema) he vist que el ls -lA mostrava alguns arxius “espenyats”. Total que he decidit fer el que jo crec que “és lo seu”: desmuntar-lo i passar-li un fsck.ext3.
Així ho he fet i la comanda no m’ha mostrat cap error:
$ sudo fsck.ext3 /dev/sdb1
e2fsck 1.41.9 (22-Aug-2009)
Backing up journal inode block information./dev/sdb1 has been mounted 2299 times without being checked, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found. Fix<y>? yesInode 14 was part of the orphaned inode list. FIXED.
Inode 15 was part of the orphaned inode list. FIXED.
Inode 8321 was part of the orphaned inode list. FIXED.
Inode 14724 was part of the orphaned inode list. FIXED.
Inode 16513 was part of the orphaned inode list. FIXED.
Pass 2: Checking directory structure
Problem in HTREE directory inode 40065: node (1) has bad max hash
Problem in HTREE directory inode 40065: node (2) has bad min hash
Invalid HTREE directory inode 40065 (/movie). Clear HTree index<y>? yesPass 3: Checking directory connectivity
Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Pass 5: Checking group summary information/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdb1: 212/78208 files (9.4% non-contiguous), 14840907/20010815 blocks
Però a partir d’aquí ja no he pogut muntar el filesystem mai més.
Només endollar el disc surten errors de lectura al syslog i en intentar muntar-lo en surten més:
Dec 29 20:11:57 rompetechos kernel: [235445.696926] sd 61:0:0:0: [sdb] Unhandled sense code
Dec 29 20:11:57 rompetechos kernel: [235445.696933] sd 61:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Dec 29 20:11:57 rompetechos kernel: [235445.696941] sd 61:0:0:0: [sdb] Sense Key : Medium Error [current]
Dec 29 20:11:57 rompetechos kernel: [235445.696949] sd 61:0:0:0: [sdb] Add. Sense: Unrecovered read error
Dec 29 20:11:57 rompetechos kernel: [235445.696959] sd 61:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 00 01 00 00 80 00
Dec 29 20:11:57 rompetechos kernel: [235445.696977] end_request: I/O error, dev sdb, sector 1
Dec 29 20:11:57 rompetechos kernel: [235445.696984] __ratelimit: 118 callbacks suppressed
Dec 29 20:11:57 rompetechos kernel: [235445.696989] Buffer I/O error on device sdb1, logical block 0
Dec 29 20:11:57 rompetechos kernel: [235445.696996] Buffer I/O error on device sdb1, logical block 1
Dec 29 20:11:57 rompetechos kernel: [235445.697024] Buffer I/O error on device sdb1, logical block 2
Dec 29 20:11:57 rompetechos kernel: [235445.697032] Buffer I/O error on device sdb1, logical block 3
Dec 29 20:11:57 rompetechos kernel: [235445.697042] Buffer I/O error on device sdb1, logical block 4
Dec 29 20:11:57 rompetechos kernel: [235445.697051] Buffer I/O error on device sdb1, logical block 5
Dec 29 20:11:57 rompetechos kernel: [235445.697061] Buffer I/O error on device sdb1, logical block 6
Dec 29 20:11:57 rompetechos kernel: [235445.697070] Buffer I/O error on device sdb1, logical block 7
Dec 29 20:11:57 rompetechos kernel: [235445.697085] Buffer I/O error on device sdb1, logical block 8
Dec 29 20:11:57 rompetechos kernel: [235445.697095] Buffer I/O error on device sdb1, logical block 9
Dec 29 20:11:59 rompetechos kernel: [235447.089082] sd 61:0:0:0: [sdb] Unhandled sense code
Dec 29 20:11:59 rompetechos kernel: [235447.089090] sd 61:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Dec 29 20:11:59 rompetechos kernel: [235447.089098] sd 61:0:0:0: [sdb] Sense Key : Medium Error [current]
Dec 29 20:11:59 rompetechos kernel: [235447.089107] sd 61:0:0:0: [sdb] Add. Sense: Unrecovered read error
Dec 29 20:11:59 rompetechos kernel: [235447.089116] sd 61:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 00 81 00 00 80 00
Dec 29 20:11:59 rompetechos kernel: [235447.089134] end_request: I/O error, dev sdb, sector 129
Tenc més o manco clar que el disc devia tenir sectors defectuosos.
Però el que no puc entendre per més que hi dono voltes, és que el fsck.ext3 m’hagi rematat el filesystem d’aquesta manera.
O vaig molt errat?
També podria esser que el disc s’hagués mort just després del fsck, però això me pareix una casualitat massa gran.
El syslog me diu que el fsck l’he llançat a les 19:09:56 (i s’ha torbat un parell de minuts) i el mount infructuós de just després a les 19:12:29; el primer error de lectura del disc el trobo a les 19:12:14. Quadra amb l’explicació que el disc s’ha mort just en aquest moment; però me sembla, com deia, mal de creure.
Fa pudor a falla física del disc: el fet que l’hagi llegit de manera exhaustiva potser l’ha acabat de trancar.
De tota manera és una putada! >_<
Jo ho he vist altres vegades amb altres FS: El disc està defectuós, però com que els sectors defectuosos estan ocupats per fitxers que no s’usen, funciona.
En fer-li el fsck provoques que el capçal passi pel sector defectuós, aleshores el firmware del disc (No devia ser Samsung?) detecta el sector defectuós i tracta de moure l’arxiu a un altre i marxar el sector com a defectuós.
El problema és que en ser un problema físic n’hi ha més de defectuosos, aleshores el firm no pot reubicar el sector i deixa la taula d’inodes inconsistent o, pitjor, la taula de particions. El sector defectuós ja no és físicament accessible (el firm ja no deixa passar el capçal per allà) i no s’ha pogut reemplaçar per cap altre.
Si el sector era crític, adéu disc.
Això abans no passava perquè els firmwares no anaven de llestos per la vida. Els fabricants ho fan perquè així si un disc té un petit defecte no es nota i es pot seguir emprant perquè només es perden uns pocs KB de tots els GB que té.
Té mala solució. Jo començaria per un dd i ho tiraria a un fitxer d’un disc més gran. Allà ja provaria de fer-hi perreries amb el fsck, ja que estaries traballant amb una imatge i no un disc físic amb un FW pel mig que fa coses que tú no saps.
Sort!
Sí Pau, que és fall de hardware del disc ho tenc claríssim. La putada és relativa, ja que no hi havia informació “crítica” al disc (crec, perque el disc no és meu
). Pero bono, perdre informació (encara que no sigui crítica) sempre emprenya, com a mínim, un poc.
Paco, no sabia això que els firmwares dels discs reubicàssin sectors de forma transparent al s.o. Podria explicar algunes coses (ah!, no és un samsung, és un maxtor).
Intentaré a veure si puc recuperar alguna cosa fent abans la imatge del disc amb dd. Tot i que “només” són 80 GBytes ja és prou per a que la cosa sigui un poc “enredosa”.
Tot i no esser informació crítica (crec!, repeteixo
), aquest tipus de coses són entretengudes de provar (quan la informació és crítica, la pressió d’haver-ho de recuperar li lleva la diversió 
).
Gràcies!
De totes maneres, pensant un poc més en el que deies, Paco («Si el sector era crític, adéu disc.»): això crec que no hauria de passar amb ext2/3.
ext2/3, si no recordo malament, coŀloca la taula d’inodes repetida a diverses ubicacions del disc (precisament per a evitar que el fall d’un sector et deixi sense tot el filesystem).
El fet que ara no pugui ni muntar-lo, me fa pensar que és la taula d’inodes que s’ha perdut. Cosa que se suposa que no hauria de passar en aquest cas (sectors defectuosos); o com a mínim no m’hauria d’haver destroçat el fsck.
Però com deia, els meus coneixements del funcionament del ext2/3 no son prou grans com per a poder afirmar això que acab de dir amb prou coneixement de causa.
No, jo tampoc en tinc molts de coneixements sobre FS. De fet, estic quasi segur de que tú en saps molt més.
Jo he vist dos casos com aquest amb NTFS + Journaling i no hi ha res a fer. El darrer cas, el capçal va aterrar sobre el plat i va causar un dany físic considerable. Es va veure quan, en enviar-lo a “Recovery Labs” el varen desmontar.
Aquesta empresa es va cobrar 1.500€ per no fer gran cosa i al final va ser un DD a un disc més gran (el disc afectat era de 500GB i trobar-ne un de 1TB no va ser bo de ver)
El problema del dany físic és que mai hi ha un únic sector afectat, de totes maneres m’has fet dubtar amb el que comentes de que ext3 duplica la taula d’inodes.
Respecte del tema FW sí, els discs venen amb FW (a mí em va petar un mirror de 2 Samsung de 500GB per no fer un update del FW que tenia un bug. Petaren els dos discs alhora) i aquest FW no és controlable des del sistema operatiu, per això el millor és desfer-se l’abans possible de tota interferència entre les eines del FS i els mitjans físics.
Ja ens contaràs si li fas l’autòpsia
Pingback: Rescatant un disc espenyat « Kiko Piris, blog (v 0.2)
Això que diuen al manual de GNU ddrescue :
«IMPORTANT! Never try to repair a file system on a drive with I/O errors; you will probably lose even more data».
Ho explica tot
Evidentment és un fall important per part meva no saber-ho. Encara que en aquest cas concret no hagués servit de molt, ja que quan vaig passar el fsck el disc no m’havia donat cap síntoma de falls de I/O.