Ayer me lleve una sorpresita. Es la primera vez que me pasaba y al
principio me asuste un poco, es lo que suele ocurrir la primera vez que te e
nfrentas a algo que desconoces. Pero voy a quitaros el miedo por si os
pasa alguna vez…
Si usais Ubuntu, sabreis que cuando reiniciais el sistema un cierto numero
de veces (si no me equivoco, creo que por defecto son 30 veces) te
hace un pequeño escaneo del estado del sistema de ficheros.
A algunos le puede parecer un fastidio, pero es un “mal” necesario.
Pues bien, yo he reiniciado miles de veces varios sistemas
(tengo varios ubuntu instalados) y siempre tras los minutos
de rigor me volvia a iniciar el entorno grafico, pero ayer me dio un error y
me dejo en consola el siguiente mensaje:
Unexpected inconsistency; RUN fsck MANUALLY (i.e. , without -a or -p options)
Ohhhhh nooooo!!!! tu no, todos menos tu please!!! , no, nooo me abandones!!! ^^
me asuste un poco al principio, pues lo normal siempre era que volvieran
a iniciar las X, y claro me quede pensando: algo se ha roto. ¿me he quedado
sin disco duro? ¿Y ahora comor recupero lo que tenia?…
Tranquilidad, es normal y eso puede pasar alguna vez. Asi que menos mal…
El sistema operativo cuando reinicia hace un chequeo del sistema de
ficheros y si detecta alguna inconsistencia en el mismo entonces ejecuta
la utilidad del sistema fsck para intentar recuperalo.
Esto suele pasar cuando el sistema se ha apagado de manera incorrecta,
ha habido un corte de luz o cualquier otra situacion similar.
Si no consigue reparar el sistema por si mismo, para la carga del entorno
grafico y te arranca una consola en modo de comandos para que tu como
root ejecutes el comando de manera manual en la particion
(montada solo como lectura).
¿Que hace este comando, fsck?
La utilidad del sistema fsck (de “file system check” o “file system
consistency check“)
es una utilidad para chequear la consistencia de un sistema de ficheros en
un sistema Unix/Linux. Se emplea para corregir los posibles errores
que hubiese en el sistema de archivos y devolver este a su estado normal.
Se aconseja emplear este comando cuando la particion este desmontada.
Vendria a ser el equivalente a los comandos scandisk y chkdsk
de Microsoft que se utilizan para detectar y corregir errores en el disco.
Su sintaxis es la siguiente:
fsck [-opciones] /dev/hdXXX (o sdXXX)
Opciones:
-a confirmar automáticamente. No recomendado.
-c comprobar bloques en el disco.
-f forzar el chequeo aunque todo parezca ok.
-v (verbose) despliega más información.
-r Modo interactivo. Espera nuestra respuesta.
-y asume yes de respuesta.
Y a mi me paso exactamente ayer ese problema. Se detecto un estado
“inconsistente” en el disco, Me mostro ese error y me dejo en modo consola
para que lo ejecutara de nuevo e intentara corregir el sistema. Asi que todo
fue tan sencillo como escribir de nuevo:
$ fsck
sin ningun parametro, responder a “yes” a las preguntas que te va
haciendo, y esperar…
Entonces intentara recuperar la informacion de los inodos corrompidos y
dejara los archivos que vaya recuperando en la carpeta “lost+found”
Cuando se ejecuta fsck , se inician 5 pasos o fases:
* Fase 1 – Chequear bloques y tamaños
* Fase 2 – Chequear rutas (pathnames)
* Fase 3 – Chequear Conectividad
* Fase 4 – Chequear referencias
* Fase 5 – Chequear Grupos de cilindros
Al terminar ya puedes reiniciar de nuevo con la combinacion de teclas
Control+D y ya deberias poder entrar en el entorno grafico.
En mi caso, No se muy bien a que fue debido, pues el sistema se cerro
correctamente y no hubo tampoco ningun corte de luz, creo que fue mas
por algo que hice de manera indebida desde la particion NTFS.
Ese dia arranque una particion con Windows y accedi al sistema de ficheros
de Ubuntu desde ella para borrar las carpetas .Trash-usuario
que es donde se almacena el contenido de lo que envias a la papelera.
Despues reinicie Linux y al intentar arrancar me dio ese error.
Creo que algo de esto (borrar las carpetas .Trash desde Windows),
no debio de gustarle.
Bueno, He hablado de inodos y de la carpeta “lost+found”, algunos
preguntaran ¿Que es eso?.
Veamoslo con mas detalle.
¿Que es un inodo?
Lo explicare por encima, tampoco quiero entrar en detalles.
Un inode es una estructura de datos
donde se almacena informacion sobre un sistema tradicional de ficheros tipo Unix
o similar.
Por cada archivo existe un inode. Estos inodes se identifican de manera
numerica.
El inode almacena informacion basica acerca del fichero, directorio o de
otro objeto del sistema de archivos.
Se pueden almacenar atributos como son:
– La longitud del fichero en bytes
– El identificador del usuario propietario
– El identificador del grupo del archivo
– El modo del fichero que indica que usuarios pueden leerlo, escribirlo,etc
– Timestamps que indican cuando el inode ha sido modificado
– Un contador de los enlaces duros que apuntan al inode
– Punteros a los bloques en disco que almacenan el contenido del fichero.
Y ahora, mas culturilla:
¿Desfragmentar un Sistema Linux?
Extraido de la wikipedia: http://es.wikipedia.org/wiki/Desfragmentación
La defragmentación es el proceso mediante el cual se acomodan los archivos
de un disco de tal manera que cada uno quede en un área contigua y sin
espacios sin usar entre ellos. Al irse escribiendo y borrando archivos
continuamente en el disco duro, éstos tienden a no quedar en áreas
contiguas, así, un archivo puede quedar “partido” en muchos pedazos a lo
largo del disco, se dice entonces que el archivo está “fragmentado”. Al tener
los archivos esparcidos por el disco, se vuelve ineficiente el acceso a ellos.
La fragmentación es el efecto que se produce debido al almacenamiento
de archivos en dispositivos como disco duro y memoria RAM por el uso del
computador. El problema de almacenamiento no contiguo de archivos se
denomina fragmentación.
La fragmentación es un problema que surge debido al ordenamiento interno
de los datos en algunos sistema de archivos. Se da muy comúnmente en
el sistema operativo Windows aunque también afecta a otras plataformas
pero en una escala mucho menor. También se produce fragmentación
dentro de la memoria del computador (memoria RAM) cuando se asignan los
procesos a los diferentes bloques de memoria. Existen dos tipos de
fragmentación: interna y externa.
Esta es una ventaja respecto a los sistemas de archivos de Windows, y
es lo que por ejemplo permite que no tengamos que “desfragmentar” un
Sistema Linux.
En Linux, los archivos se van colocando por todo el disco y con suficiente
espacio por lo que si tuviera que crecer el archivo no habria
problemas, y si se reduce el tamaño, tampoco, pues los archivos se van
reordenando y acomodando. dificilmente se fragmenta un archivo y siempre
podria reubicarse a otra zona , por ello la fragmentacion es practicamente
minima.
En un sistema windows, los archivos se dejan “donde se puede” y al
comienzo del disco (unos archivos a continuacion de otros) y eso hace
que con el tiempo si el archivo crece tenga que fragmentarse para disponer
de espacio.
o a la inversa, si el tamaño del archivo se reduce, van quedando huecos
“sin rellenar”.
Cuando el sistema tiene pocos ficheros, la velocidad de acceso es muy
rapida, pero conforme aumenta el numero de los mismos, el acceso se va
deteriorando, preciamente por estas reubicaciones, que van dejando huecos
en el disco y crece la fragmentacion.
Esto obliga a que cada cierto tiempo, se tengan que usar aplicaciones
para reordenar esos archivos (mejor de lo que estan actualmente)
aprovechando esos huecos para archivos pequeños y reordenando los
archivos grandes en zonas contiguas, evitando que queden numerosos
huecos entre archivos sin usar.
Veamos un ejemplo sencillo: No exacto, pero solo para que se capte
la idea.
Supongamos que tenemos 2 archivos, uno con contenido “AA” y otro con
contenido “BB”
En un sistema Windows los almacenariamos de manera consecutiva en
el disco:
“AA”»BB”………………..
pero que pasa si ahora “AA” crece a “AAAA”.
Pues que al no disponer de espacio contiguo se fragmenta.
“AA”»BB”»AA”…………….
Esto cuando tienes 2 ficheros no pasa nada. pero cuando tienes miles y
miles de archivos ya es un problema.
¿Y ahora en Linux que pasaria?
Pues los almacenariamos no al principio del disco sino donde tuvieran
espacio:
…….”AA”……………..”BB”……………
y “AA” crece sin problemas:
…….”AAAA”……………”BB”……………
Una explicacion parecida puedes encontrar aqui o aqui.
¿Que es la carpeta lost+found?
No confundamos con “lost”, la serie de television (chiste tonto, pero
tenia que hacerlo ^^).
Esta una carpeta que existe por cada una de las particiones que tengamos,
y en ella se depositan los archivos que pueden ser recuperados cuando ocurre
una recuperacion de un estado inconsistente de ficheros.
Es decir, lost+found contiene los archivos que son encontrados cuando
se examina el disco en busqueda de errores.
Si te valen para recuperar informacion, los usas, si no te sirven, puedes
borrarlos tranquilamente para liberar espacio.
Pero esto queda mejor explicado en estos foros: (Copy & Paste)
Extraido de:
http://www.velug.org.ve/archivo/l-linux-1999-November/011098.html
>Aprovechando, y disculpen mi ignorancia. Que significa, que hace,
>cuando se usa el directorio lost+found en Unix, porque parece
>que fuese interno de Unix o me equivoco ?
En sistemas de archivo clásicos Unix (sin jornal), se confía en la
_consistencia_ del mismo antes de montarlo. Es decir, si el filesystem no
está consistente, no se puede montar. Cada vez que uno desmonta un
filesystem, el kernel sincroniza toda la información (lo que está pendiente
de escritura se escribe) y hace una marca en el superbloque del mismo
indicando “este filesystem está consistente” y lo cierra; cada vez que uno
monta un filesystem, el kernel revisa dicha marca, y si no está, no solamente
no lo monta sino que avisa que el filesystem necesita ser revisado. Esto se
hace con la clásica herramienta fsck.
Pueden ocurrir diversos tipos de falla en un filesystem que no fue bajado
correctamente, los detalles los encuentras en cualquier documentación
relacionada con filesystems Unix sin jornal. Una de las posibles fallas es
que existan bloques de datos en _uso_, que no están asociados a ningún
archivo; en estos casos fsck brinda al administrador la oportunidad de
“encadenar” dichos bloques a un archivo ficticio. Como el filesystem no está
montado, es imposible que el administrador construya un archivo, y por
otro lado, para construir un archivo es _necesario_ que exista un
directorio (en caso de dudas, la documentación del sistema de archivo te
explica por qué); en conclusión, es necesario que _antes_ de hacer
fsck _exista_ un directorio y que dicho directorio sea _conocido_:
lost+found. Durante la reparación del sistema de archivo, fsck ubica el
directorio y cualquier conjunto de bloques sueltos es encadenado en dicho
directorio, con un nombre de archivo igual al número de bloque
(algo como #737235) de manera que el administrador pueda revisarlo
posteriormente a ver si se trata de algo importante. Muchos administradores
acostumbran eliminar dicho directorio (cosa que no es recomendable), y
luego se dan cuenta que es buena idea tenerlo… no basta con que el
directorio _exista_, es necesario que tenga varios bloques reservados
(vacíos), en caso de necesitar enlazar muchas cadenas.
Por ejemplo, en Linux, un lost+found típicamente tiene 12k; bórralo con
rmdir y vuelve a crearlo… ¡sorpresa! ahora solamente tiene 1k. fsck
no _puede_extender el tamaño del directorio mientras corre, de manera
que si en 1k no caben todos los apuntadores a tus bloques perdidos…
pues el resto se pierde.
En general, tener entre 8-16k para el directorio vacío es suficiente.
Otro ejemplo, en HP/UX, un lost+found tiene 8k; un directorio nuevo,
tiene 24_bytes_. En Solaris, un lost+found tiene 8k; un directorio nuevo,
tiene 24 bytes. Que sean iguales no indica un standard, simplemente que
la reserva de bloques para directorio no es agresiva, como en Linux.
En IRIX, un lost+found tiene 10k; un directorio nuevo tiene 512 bytes.
Lo _consistente_ en todos los casos es que el lost+found está vacío pero
tiene varios bloques reservados.
Si eliminaste el lost+found y quieres volver a crearlo, lo que debes hacer
es crear dentro varios archivos (vacíos, no necesitan datos) de manera
que se extienda el tamaño del directorio, y luego eliminar los archivos de
manera que quede el directorio vacío y con todos sus bloques asignados.
y extraido de http://www.velug.org.ve/archivo/l-linux-2003-March/043536.html
> Logre recuperar algo de una particion ( /dev/hda4 ) la cual estaba
> perdida, la monte en /home, pero toda la informacion que contenia
> la ubico
> en el directorio /home/lost+found.
>
> Exite alguna forma de restaurar lo ubicado en este directorio?
Lo que está en ese directorio ya está restaurado. Está “tal cual”, si te
sirve bien, si no también.
> El contenido de dicho directorio es de la siguiente forma:
>
> #147232
“Pude recuperar el i-node 147232 y aquí está lo que encontré”.
> #147233
> #147234
> #1472..
>
> Sin importar si era un directorio o un archivo, los permisos del
> directorio o archivo continuan perteneciendo al usuario inicial
>
> Alguien me puede ilustrar como recuperar dicha informacion…
mv, cp y trabajo manual si es que no se pudo recuperar todo. Si uno
recuerda que en Unix los archivos son definidos por el i-nodo,
inmediatamente razona que es _imposible_ para fsck determinar como se
llamaba el archivo (porque el nombre no está en el i-nodo) [1]; eso es
trabajo del administrador, quizás con la ayuda del dueño del archivo.
[1] Si fsck puso algo en lost+found es porque en una de sus fases
encontró un i-nodo que no tenía ningún nombre que lo referenciara.
Asi que basicamente, tras una recuperacion del estado del sistema
en este directorio encontraras los archivos que se han podido recuperar.
Pero no podras referenciarlos por su nombre, al no estar disponible
esa informacion.
Tendras que editarlos a mano y cambiarles el nombre y renombrarlos
si los conoces.
Tampoco se asegura al 100% que sea informacion valida o este
completa. Si es texto plano, puede que recuperes algo de informacion,
si son binarios, tal vez si o tal vez no.
Pero esto es lo que hay…mejor que nada…
…Lastima que no podamos emplar fsck para corregir un sistema corrupto en politica…
Escrito por xoanyeta 
Xoanyeta's Weblog 