Así como hay días buenos y días malos, también los hay en semanas y en años. Esta semana promete ser malísima. Algunos problemas que pasaron a ser menores cuando me encontré con lo siguiente:
Filesystem "sda5": XFS internal error xfs_bmap_read_extents(1) at line 4565 of file fs/xfs/xfs_bmap.c. Caller 0xc02e7c99 [<c02ca11e>] xfs_bmap_read_extents+0x488/0x4a2 [<c02e7c99>] xfs_iread_extents+0xa0/0xbb [<c02e5b5f>] xfs_iext_realloc_direct+0xb3/0xc1 [<c02e7c99>] xfs_iread_extents+0xa0/0xbb [<c02c2a54>] xfs_bmap_last_offset+0x94/0xdc [<c02d5269>] xfs_dir2_isblock+0x1b/0x60 [<c0324085>] __make_request+0x384/0x495 [<c02d59fb>] xfs_dir_lookup+0x8e/0xeb [<c02c7615>] xfs_bmapi+0x25b/0x1fd7 [<c02fb04f>] xfs_dir_lookup_int+0x2c/0xd4 [<c01230c4>] down_write+0x8/0x10 [<c02e41ad>] xfs_ilock+0x47/0x67 [<c02fe944>] xfs_lookup+0x50/0x76 [<c05ff4cc>] __mutex_lock_slowpath+0x1ac/0x1b4 [...]
Esa es una de las particiones de un servidor con problemas. Luego continúa:
# xfs_repair -n /dev/sda5
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- scan filesystem freespace and inode maps...
- found root inode chunk
[...]
Phase 6 - check inode connectivity...
- traversing filesystem starting at / ...
entry "etc" in directory inode 128 points to free inode 1310848, would
junk entry
corrupt dinode 786561, (btree extents). This is a bug.
Please report it to xfs@oss...
El énfasis es mío. Hay que notar que la opción -n de xfs_repair indica que muestre lo que haría, pero no toma acción alguna. Previamente, xfs_check también se lució con:
# xfs_check /dev/sda5 [...] dir 1310848 block 8388608 extra leaf entry fc4e7e74 e7 dir 1310848 block 8388608 extra leaf entry fcdbb5f3 8f dir 1310848 block 8388608 extra leaf entry fddcbf74 164 /usr/bin/xfs_check: line 28: 14691 Segmentation fault xfs_db$DBOPTS -i -p xfs_check -c "check$OPTS" $1
Buscando por aquí y por allá, me encontré con 2 posibles alternativas:
- Memoria RAM con problemas, de donde se hayan guardado datos corruptos en disco.
- Un fallo en el módulo XFS del núcleo.
Afortunadamente, los problemas no ocurrían en la fase 1 ó 2, sino que bien avanzado. XFS está hecho para ser utilizado en hardware robusto. Un reset de un dispositivo SCSI o IDE, que a veces se dejan ver en los registros del sistema, es razón suficiente para causar corrupción de datos en el sistema de archivos. No es el caso, pero sirve para ejemplificar la situación.
Al menos, después de la recuperación, en el directorio lost+found quedaron guardados archivos completos. No pedazos de datos que usualmente veía con ext2/ext3 (cuando habían problemas).
Justo en un mal momento. En una mala semana. Me ha consumido muchas horas y concentración. La planificación de mis estudios se me fue a las pailas. Aún quedan datos por verificar y reconstruir.

Odio estas cosas... y además aquí cuando llega el verano comienzan a aparecer... argh!
Hoy es uno de esos dias, donde gustaria tener ZFS en Linux :/
Alberto, no sé si confiaría los datos en un sistema de archivos nuevo. Al menos dudaría en un equipo en producción.
Hola negrito: Con eso mi semana seria como ni te cuento
jajajajaj
Un abrazo
Roberto Grandon
ReiserFS tal vez sea mas "lento" que XFS, pero sin duda es mas robusto. Ademas, XFS no es buen amigo de LVM (que uso en todos mis sistemas) por aquello de que no permite (o permitia, cuando lo probe hace tiempo) reducir el tamaño del FS, cosa bastante necesaria a la hora de redimensionar volumenes.
Mi recomendación en estos casos es ejercitarse en "El Arte de las Copias de Seguridad" con el Backup & Recovery de O'Reilly... ;)