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