fallo de disco al borrar

Horst H. von Brand vonbrand en inf.utfsm.cl
Mie Jul 4 22:46:47 CLT 2007


Pablo Allietti <pablo en lacnic.net> wrote:
> On Wed, Jul 04, 2007 at 05:25:54PM -0400, Horst H. von Brand wrote:
> > Horst H. von Brand <vonbrand en inf.utfsm.cl> wrote:
> > > Pablo Allietti <pablo en lacnic.net> wrote:
> > > > paso a explicar mi problema, un administrador "descuidado" con el
> > > > usuario root, dejo corriendo un scp -r de otro server, lo que ocasiono
> > > > esta persona es que fuera todo redundante y el disco por lo cual se
> > > > lleno.... 260 Gb llenos en 1 solo folder con un monton de archivos.
> > > >
> > > > ahora cuando hago un rm -Rf * demora unos 2 minutos y da errores de
> > > > Inode y otras cosas que no tengo como para mostrarles.
> > > 
> > > fsck(8) es tu amigo; en casos recalcitrantes mke2fs(8). Y ve si no
> > > habran archivos con nombres que comienzan en '.'...
> > 
> > Pablo me indico que parece tener una estructura recursiva inmensa
> > (posiblemente un loop en el filesystem?) bajo el directorio pifiado.
> > 
> > Que sistema de archivos es?
> 
> ext3

Hum... eso es raro.

> > Tal vez unlink(1) (como root) te deje pitearte el directorio de una,
> > despues de esa clase de crimenes es *imperativo* correr fsck(8). Que
> > segurmente chillara que te lo encargo...

> unlink es para archivos no?

En rigor, unlink(2) rompe un enlace (normalmente a un archivo, pero tambien
hay enlaces a directorios). En algunos Unices/sistemas de archivo puedes
romper enlaces a directorios con unlink(3) (~-> unlink(1)) si tienes los
privilegios adecuados (~-> root); claro que quedan cosas chasconeadas y
fsck(8) es obligatorio para reparar el desorden resultante. Ver "info
unlink".

[Odio la mania FSF-istica de meter todo lo que debiera estar en el man en
 un info...]

Una operacion aun mas delicada seria cirugia via debugfs(8)...

>                             yo tengo ademas todos directorios y el lio
> empieza con el directorio openoffice :(

> > Tienes todo al dia (particularmente e2fsprogs, si tienes ext<ALGO>
> > alli; o el paquete del caso para el FS)?

> todo al dia

> > Posiblemente find(1) de una lista que se pueda pasar a rm(1), o sea,
> > quiza algo del corte:
> > 
> >   find -depth . | xargs rm -rf
> > 
> > salve la situacion?
> > -- 
> 
> lo mismo error. :( ni un tar me deja crear como para hacer backup. 

No puedes respaldar el resto? 


Y si escribes tu propio "rm -rf" que se meta recursivamente en el
directorio y se vaya cepillando las cosas en postorden? Para esto
seguramente deberas ver de encontrar una forma compacta de representar el
"donde estoy" en la recursion (porque si es /muy/ profundo, te quedaras sin
memoria). Posiblemente simplemente descender, y antes de masacrar "dir" ir
a "dir/..", parando cuando vuelves a tu punto de partida (identificado por
inodo, tal vez?) Hummm... hasta en shell se puede hacer eso (no muy
eficientemente, claro esta ;-)

Busca lo que se discute por alli respecto de la "gracia":

  while true; do touch x; mkdir y; cd y; done

(si, obviamente existe en decenas de formas distintas).
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513


Más información sobre la lista de distribución Linux