# Limpiar disco de archivos inútiles

## Latinvs

Hola, a todos.

Hacía tiempo que no pasaba por aquí, pero tarde o temprano uno tiene que dar la brasa un poco en los foros, jeje.

Bueno, quería preguntaros algo seguramente elemental para los "mostros" del foro pero que para mí no lo es tanto:

1. ¿Pasa algo si se borran todas las carpetas menos la de mi arquitectura en /usr/src/linux/arch/? Son más de 130 MB y 15.000 archivos (me quedan poco más de 100.000 inodos libres en esa partición, así que preferiría no malgastar) en carpetas referentes a procesadores Alpha, Arm, Sparc y otras de cuya existencia ni siquiera tenía noticia. Me mosquea que carpetas como"alpha"; o "x86" contengan más archivos que la de mi máquina, "x86_64", donde de hecho sólo hay un enlace a "bzimage", asi que mejor pregunto antes de liarla.

2. A pesar de que tengo la bandera USE "doc" deshabilitada, en mi /usr/share/doc hay cerca de 160 MB con unos 9.000 archivos, casi todos registros de cambios, información de los autores, "ridmíes", "tudúes" y similares. ¿Pasa algo si mando a todos esos parásitos a tomar por saco, XD, o algún programa se me quejará?

3. Y ya que hablo de parásitos, ¿se puede decir a Portage de alguna manera que no me llene el disco duro con todos los ebuilds del universo, que no voy a instalar jamás? ¿Hay alguna opción para que use alguna especie de base de datos o listado, parecido a otros instaladores, que pueda leer y que simplemente descargue los ebuilds de los programas que quiero instalar y de sus dependencias? (ya imagino que no, al menos ni en el man ni en la web he encontrado nada en ese sentido, pero bueno, mejor preguntar a los que sabéis más)

Si no es posible, ¿pasaría algo por eliminar todos esos ebuilds? Estaba pensando en un guión que tras cada instalación o actualización de mi sistema elimine todos los ebuilds salvo los que estén registrados en world, system, y no sé si algún registro más.

Entiendo que un "emerge -s" no encontraría más que los ebuilds que yo no hubiese borrado, pero me da igual, siempre consulto los paquetes que me interesan en gpo.zugaina.org que además me informa de lso que hay en los overlays que yo no tengo; y tampoco habría problema al instalar puesto que siempre sincronizo mi portage antes de instalar, actualizar o "revdep-rebuildear", o sea que los ebuilds se me vuelven a copiar como si nunca hubiese tocado nada, no? 

¿Toda esta teoría es válida o si borrase esos millares de ebuilds mi sistema cascaría?

Gracias, y saludos.

----------

## opotonil

Para la 3 hechale un vistazo a esto (creo que es lo que mas se puede acercar):

http://www.gentoo.org/doc/es/handbook/handbook-x86.xml?full=1#book_part3_chap5

En cuanto a la 1 realmente ni idea, pero entiendo que en caso de liarla con que reinstales las sources correspondientes otra vez solucionado.

Salu2.

----------

## gringo

1 - si pasa, probalemente te cargues las fuentes del kernel y no las podrás volver a usar. Las arquitecturas comparten archivos esenciales en casi todo el árbol y si te cargas alguno de ellos simplemente no se podrá crear un kernel nuevo.  Supongo que no pasa nada si te cargas el arbol de una arquitectura minoritaria ( o igual si, yo nunca he probao ...) pero por poner un ejemplo, dentro del kernel ya no existe la arquitectura x86_64, es x86.

Dicho esto, si estás seguro de que no tienes ningún driver ni ningún software que necesite las fuentes del kernel, puedes eliminarlas por completo.

2 - no pasa nada, puedes eliminarlas si quieres y si no estás leyendo las man p.ej., puedes añadir a tus FEATURES noman nodoc y noinfo.

Tb. puedes echar mano de la herramienta localepurge que elimina todo archivo man y demás que no sean lo que estén en el idioma que tu le digas.

lo otro ya te lo contestó opotonil, este es mi rsync_exclude p.ej. :

```
app-accessibility

app-antivirus

app-backup

app-emacs

app-forensics

app-vim

app-xemacs

dev-ada

dev-dotnet

dev-embedded

dev-games

dev-haskell

dev-lisp

dev-ml

dev-php

dev-php5

dev-ruby

dev-scheme

dev-tcltk

dev-tex

dev-texlive

dev-tinyos

games-*

gnustep-*

gpe-*

lxde-*

kde-*

mail-filter

media-radio

net-news

net-nntp

net-proxy

net-im

net-voip

net-irc

rox-*

sci-*

sec-policy

sys-cluster

sys-freebsd

www-apache

www-misc

www-apps

www-servers

xfce-*
```

saluetes

----------

## Stolz

Para liberar espacio también puedes recurrir a las opciones --depclean y --prune de emerge (siempre con cabeza y haciendo copias antes). Un método que a mi ha venido muy bien es el script squash_dir (disponible en el overlay de mv): Comprime un directorio en un fichero que luego monta en modo rw. En caso de que se produzcan cambios en el directorio, al apagar el ordenador se recomprime de forma transparente.  Es ideal para directorios que contengan muchos ficheros de texto (como portage o el kernel). Tienes instrucciones de cómo usarlo en mi HitHub (en inglés).

----------

## gringo

 *Stolz wrote:*   

> Un método que a mi ha venido muy bien es el script squash_dir (disponible en el overlay de mv): Comprime un directorio en un fichero que luego monta en modo rw. En caso de que se produzcan cambios en el directorio, al apagar el ordenador se recomprime de forma transparente.  Es ideal para directorios que contengan muchos ficheros de texto (como portage o el kernel). Tienes instrucciones de cómo usarlo en mi HitHub (en inglés).

 

interesante, había leído sobre esto pero no lo había probado aún. 

Tienes alguna idea de cuánto tiempo le lleva (des)comprimir portage o las fuentes del kernel p.ej. ?

saluetes

----------

## Stolz

Descomprimir sucede en el arranque y es tan rápido que no me da tiempo a verlo. Es prácticamente como cualquier otro servicio de /etc/init.d/. Comprimir sí es mas lento, da tiempo a ver la barra de progreso de mksquashfs cuando apagas el ordenador, pero aun así, son unos pocos segundos y solo ocurre cuando hayan cambios en los directorios (emerge --sync o recompilar/instalar kernel). Ahora mismo no estoy en casa y no lo puedo mirar, pero a ojo (y puede que meta la pata totalmente), comprimir /usr/src (suelo tener al menos 2 kernels en él) que es el más lento con diferencia, diría que tarda unos 40s con el algoritmo lzo. En cuanto llegue a casa te doy datos reales.

Si te corre prisa en este hilo se trata el tema, tal vez ahí te puedan dar tiempos. Yo no he leído porque con el README del paquete tuve bastante. Aunque no lo menciono en las instrucciones de HitHub, a la hora de configurar existe la variable THRESHOLD. Si los cambios no superan en tamaño lo que se indique en THRESHOLD no se recomprime el directorio, simplemente se aplican los cambios a la versión anterior ya comprimida. Supongo que esto es útil par ordenadores lentos o para directorios grandes cuyos cambios suelan ser pequeños.

Saludozzzzzzz

----------

## gringo

 *Quote:*   

> En cuanto llegue a casa te doy datos reales. 

 

na, tranqui, con lo que has comentao llega y sobra. 

 *Quote:*   

> Si te corre prisa en este hilo se trata el tema, tal vez ahí te puedan dar tiempos

 

si, lo he leído un par de veces ya aunque como digo nunca me animé a probarlo.

Voy a probar este fin de semana a ver que tal.

EDITO : estoy leyendo un poco y ando un poco perdido así que perdón si pregunto chorradas : entiendo que tengo que usar aufs del mv overlay porque estoy ejecutando un kernel 3.x. ( osea tengo que ejecutar AUFSBRANCH=aufs3.0 emerge -1 aufs), pero que se supone que hace el USE all-patches ? Porque no entiendo que hace el ebuild con esta USE ...

gracias y saluetes

----------

## Stolz

gringo, tiempos con un i5 2500: 

 - Comprimir Portage menos de 6 segundos. Se queda en 52M.

 - Comprimir un kernel (3.0.6 con fuentes + objetos), menos de 20 segundos. Se queda en 153M.

A la hora de instalar, a mi me intentó instalar sys-fs/aufs2 pero me dio fallo por tener un kernel muy reciente. Entonces modifique el ebuild para tener en RDEPEND a  sys-fs/aufs3 en vez de aufs2. Se me instaló sin problemas pero me daba fallos al la hora de montar. Al final probé con sys-fs/unionfs-fuse (también en el overlay de mv) y entonces funcionó todo. Si te digo la verdad unionfs/aufs ni los conocía hasta que no me dio por probar este script. Entre sys-fs/aufs2 sys-fs/aufs23 sys-fs/unionfs-fuse sys-fs/funionfs sys-fs/unionfs y sys-fs/aufs no se ni cual es el nuevo, ni cual es el bueno, ni las diferencias ... solo se que me funciona.

Para que quede claro, esto es todo lo que hice:

```
emerge -n layman

layman -f

layman -a mv

emerge --sync

USE=lzo" emerge -n sys-fs/squashfs-tools sys-fs/unionfs-fuse sys-fs/squash_dir
```

----------

## gringo

muchas gracias Stolz  :Smile: 

ya lo tengo funcionando, de momento sólo con portage, y como tu decías es imperceptible.

Los detalles de la máquina son estos. Sustituí en su momento el disco que venía de serie son un ssd de intel.

Dejo aqui las instrucciones de como lo hice, ya que estoy ejecutando un kernel 3.1-git9 + parches :

- añadi a mi /etc/portage/package.use/sqaush_crap

```
sys-fs/squashfs-tools lzo progress-redirect

sys-fs/aufs kernel-patch
```

- instalé antes de nada aufs del overlay mv con la rama para mi kernel :

```
AUFSBRANCH=aufs3.x-rcN emerge -av1 aufs
```

- recompilé el kernel y comrpobé que efectivamente estaba todo en su sitio :

```
[...]

[0.574087] aufs 3.x-rcN-20111010

[...]

[0.573629] squashfs: version 4.0 (2009/01/31) Phillip Lougher

[...]

1.181269] loop: module loaded

```

- luego seguí básicamente las instrucciones de Stolz.

saluetesLast edited by gringo on Mon Oct 24, 2011 8:31 am; edited 1 time in total

----------

## Latinvs

Perdón por la tardanza en responder.

Estupendas las aclaraciones e indicaciones.

Los man sí los consulto con frecuencia pero de lo demás parece que me voy a poder deshacer de varios centenares de megas y millares de inodos ocupados. Mañana, domingo de resaca, toca limpieza.

Gracias cienes,  :Smile: 

----------

