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.
_________________
Vir prvdens non contra ventvm mingit

opotonil · l33t Joined: 17 Jun 2005 Posts: 801 Location: 127.0.0.1

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 · Advocate Joined: 27 Apr 2003 Posts: 3793

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. :

Stolz · Posted: Thu Oct 13, 2011 9:47 am Post subject:

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 · Advocate Joined: 27 Apr 2003 Posts: 3793

Stolz · Posted: Thu Oct 13, 2011 11:21 am Post subject:

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 · Advocate Joined: 27 Apr 2003 Posts: 3793

Stolz · Posted: Thu Oct 13, 2011 6:25 pm Post subject:

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:

gringo · Advocate Joined: 27 Apr 2003 Posts: 3793

muchas gracias Stolz :-)

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

Latinvs · Posted: Sat Oct 22, 2011 5:36 pm Post subject:

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,

_________________
Vir prvdens non contra ventvm mingit