# [FS] Fragmentación del disco (SOLUCIONADO)

## sirope

HoLa!   :Very Happy: 

Duda existencial:

¿Por qué decargar y descargar ebuilds que nunca serán utilizados? Cada programa es una carpeta con un ebuild, manifiest, parches, coca cola y palomitas dentro... ¿No provocará esto demasiada fragmentación en el disco?..

Sé que pueden bloquearse secciones de Portage para ser ignoradas en un --sync, pero aún así las sincronizaciones se hacen eternas.. ¿Por qué no mejor descargar una simple lista de ebuilds disponibles? Un emerge algo descarga el ebuild con sus medicinas y mi disco no tiene que soportar todo el árbol, sino un simple archivo de texto plano.

¿Qué razón hay para no hacerlo de este modo?

 :Confused:   :Confused: Last edited by sirope on Sat Jan 12, 2008 4:09 pm; edited 1 time in total

----------

## pcmaster

emerge --sync no descarga el código fuente de los programas, sólo el ebuild y poca cosa más.

emerge programa descarga el código fuente y lo compila.

La información del emerge --sync es neecsaria para comprobar las dependencias, si bien quizá sí sería buena idea aligerarlo un poquito, por ejemplo de parches y esas cosas (aunque los que se bajan en un emerge --sync suelen ser muy pequeñitos) que podrían bajarse al emerger el paquete, si son necesarios.

----------

## i92guboj

 *sirope wrote:*   

> HoLa!  
> 
> Duda existencial:
> 
> ¿Por qué decargar y descargar ebuilds que nunca serán utilizados? Cada programa es una carpeta con un ebuild, manifiest, parches, coca cola y palomitas dentro... ¿No provocará esto demasiada fragmentación en el disco?..
> ...

 

Depende, si tienes una partición para portage solito, entonces el problema de la fragmentación es irrelevante.

 *Quote:*   

> 
> 
> Sé que pueden bloquearse secciones de Portage para ser ignoradas en un --sync, pero aún así las sincronizaciones se hacen eternas.. ¿Por qué no mejor descargar una simple lista de ebuilds disponibles? Un emerge algo descarga el ebuild con sus medicinas y mi disco no tiene que soportar todo el árbol, sino un simple archivo de texto plano.
> 
> ¿Qué razón hay para no hacerlo de este modo?
> ...

 

Recuerdo haber leído algo en las líneas de esto y no recuerdo cuáles eran los motivos (si es que los había), si encuentro algo ya postearé un link o similar. Yo personalmente no creo que los tiempos de sync sean tan largos (y he usado Gentoo durante dos años o más en un equipo que se conectaba con un modem de 56kbps  :Razz:  ). Para hacer un sync no hay que estar atento ni nada similar, puedes hacerlo de noche mientras duermes con un trabajo cron (y programarlo de paso para apagar el ordenador después si así lo deseas).

----------

## sirope

Gracias por responder.. 

Había considerado el tema de la partición, pero un disco normal no puede soportar más de 4 particiones.. Tengo exactamente 4, y no quisiera tener que hacer particiones lógicas.   :Wink: 

El código de fuente, claro que no se descarga, pero sí un par de parches y cada programa trae bastantes cosas dentro.

La molestia no es tanto descargar todos los ebuilds, sino también actualizar el caché de Portage, que en mi caso es la etapa más larga.. Tal vez los tiempos del --sync no sean tan largos, pero son enormes cuando me recuerdo de los dos o tres archivos de texto que descargaba con Arch, el --sync no duraba más de 10 segundos.

Ahora tengo que idearmelas para encender el router a media noche.. Le daré un vistazo a la actualización en diferido, Portage podrá enviarme el log por email.   :Very Happy: 

Salu2

----------

## gringo

 *Quote:*   

> Había considerado el tema de la partición, pero un disco normal no puede soportar más de 4 particiones.. Tengo exactamente 4, y no quisiera tener que hacer particiones lógicas.  

 

por ... ? no veo que problema hay con las lógicas ...

 *Quote:*   

> La molestia no es tanto descargar todos los ebuilds, sino también actualizar el caché de Portage 

 

hay un truquillo pá eso que *creo* que debería funcionar tb. con la versión estable de portage :

como root :

- echo "portdbapi.auxdbmodule = cache.metadata_overlay.database" >> /etc/portage/modules

- renombra /var/cache/edb/dep/usr/portage a lo que quieras  (simple copia de seguridad por si las moscas)

- añade -metadata-transfer a las FEATURES del make.conf.

- y luego ejecuta emerge --sync pá ver si todo va bien.

no he notado ningún problema en el funcionamiento de portage.

saluetes

----------

## i92guboj

 *sirope wrote:*   

> Gracias por responder.. 
> 
> Había considerado el tema de la partición, pero un disco normal no puede soportar más de 4 particiones.. Tengo exactamente 4, y no quisiera tener que hacer particiones lógicas.  
> 
> 

 

¿Por algún motivo en concreto? Linux no tiene problemas con particiones lógicas ni de ningún tipo. De hecho, muchas veces simplemente creo una gran partición extendida y luego todas las particiones las creo dentro de esta. Así se ahorran problemas al redimensionar, porque la partición extendida y el disco físico son casi lo mismo, y es un límite menos a tener en cuanta al ir a cambiar el tamaño de alguna partición (aunque tampoco es que yo suela cambiar el tamaño de ninguna partición).

 *Quote:*   

> 
> 
> El código de fuente, claro que no se descarga, pero sí un par de parches y cada programa trae bastantes cosas dentro.
> 
> La molestia no es tanto descargar todos los ebuilds, sino también actualizar el caché de Portage, que en mi caso es la etapa más larga.. Tal vez los tiempos del --sync no sean tan largos, pero son enormes cuando me recuerdo de los dos o tres archivos de texto que descargaba con Arch, el --sync no duraba más de 10 segundos.
> ...

 

Creo que a día de hoy, y sin otra alternativa a la vista, la opción más acertada sería combinar la exclusión de las ramas de portage no usadas con la actualización vía cron, o bien simplemente un "emerge --sync; layman -S; sudo /sbin/shurdown -r now" o similar. Uso ; en lugar de && porque si falla el sync por algún motivo el pc no se apagaría. Si prefieres ver los errores puedes cambiar ; por && y si hay fallo quedará encendido para que veas lo que pasó.

Necesitarás configurar sudo para que te deje usar shutdown. 

También puedes escribir tu propio script sencillo para la tarea, y logear los resultados a un fichero para ver al día siguiente si pasó algo.

----------

## sirope

No creo lógicas porque tendría que redimensionar una primaria, crear una extendida y luego lógica. Entonces / me queda como /dev/hda20.   :Very Happy:  Bromas, en caso de volcar las particiones no dudo en meter swap y /usr/portage en dos lógicas.. ¿O será mejor todo /usr?

i92guboj, gracias por la info, el && me había dejado la máquina encendida más tiempo del que quisiera, de ese modo puedo ver el error, pero queda encendida, al usar ; se apagaría, pero en vez de crear un script para mandar el error a otro lugar, pensaba usar sendmail, aunque si falla el sync a causa de la conexión, no sé donde quedaría el log..

 :Very Happy:   :Very Happy:   :Very Happy: 

----------

## Cereza

 *sirope wrote:*   

> aunque si falla el sync a causa de la conexión, no sé donde quedaría el log..

 

```
emerge --sync > archivo
```

 Guardará toda la salida del sync en dicho archivo y podras revisarlo cuando vuelvas. Puedes usar esto dentro de un pequeño script como te ha sujerido i92guboj.

----------

## the incredible hurd

Sinceramente, ¿no usas ni eix ni eix-sync?

Allá cada cual...

eix-sync sólo ejecuta emerge --sync pero hace absolutamente todo lo demás mencionado automáticamente, con -v si quieres ver toda la parafernalia y sin parámetros para que no te llene los logs de cron de basura completamente innecesaria.

eix es extraordinario, si no lo usas.... ¡úsalo ya!

----------

## ekz

 *gringo wrote:*   

> 
> 
> hay un truquillo pá eso que *creo* que debería funcionar tb. con la versión estable de portage :
> 
> como root :
> ...

 

Ese truquillo es genial, yo lo uso hace bastante tiempo y nunca me ha dado problemas (además de una partición XFS para /usr/portage   :Razz:  )

Saludos

----------

## vguardiola

Si lo que quieres es que el sync no se baje todo, por ejemplo si es un servidor sin X, para que vas a querer KDE,GNOME, etc hay la opcion de poner en el make.conf este parametro

PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes"

y en el archivo pones las ramas que no quieres del portage, si ya las tienes deberas borrarlas y la proxima vez que hagas el sync ya veras como no se las baja. Para mas info mira en http://gentoo-wiki.com/TIP_Exclude_categories_from_emerge_sync

Saudos

----------

## i92guboj

 *sirope wrote:*   

> .. ¿Por qué no mejor descargar una simple lista de ebuilds disponibles? Un emerge algo descarga el ebuild con sus medicinas y mi disco no tiene que soportar todo el árbol, sino un simple archivo de texto plano.
> 
> ¿Qué razón hay para no hacerlo de este modo?
> 
>  

 

No he encontrado ningún post hablando del tema (pero estoy seguro de que alguien lo ha sacado alguna vez a relucir).

Uno de los problemas potenciales que me vienen a la cabeza es que dicho esquema alargaría el cálculo de las dependencias bastante (y ya es bastante lento, aunque más rápido que hace uno par de años sin duda).

Para hacer lo que dices habría que modificar el sistema y crear una base de datos centralizada con las dependencias, porque en el sistema actual de ebuilds, las dependencias están incrustadas en los mismos ebuilds. Esto quiere decir que habría que ir descargando ebuilds, recalculando dependencias, descargando más ebuilds y calculando las dependencias de las dependencias... No se si hay más pegas, seguramente si, pero esa es la primera que me vino a la cabeza.

----------

## the incredible hurd

Si lo que te preocupa es la fragmentación de portage, adapta este script, pacman-optimize que es de archlinux:

http://devfiles.jlime.com/Archlinux/core/pacman-3.0.1/unpacked/bin/pacman-optimize

 *pacman-optimize wrote:*   

> Because pacman uses many small files to keep track of packages, there is a tendency for these files to become fragmented over time. This script attempts to relocate these small files into one continuous location on your hard drive.  The result is that the hard drive should be able to read them faster, since the hard drive head does not have to move around the disk as much.

 

La única pega que le encuentro es que no hace un /bin/sync después de copiar/mover el "portage" de archlinux (no sé cómo le llamarán ellos). Así evitarás que se queden en los buffers/cache algunos archivos y que un proceso con mayor prioridad escriba antes y, consecuentemente, se fragmente el árbol.

Si consigues terminar de modificar el script antes que yo, pégalo aquí. Aunque me pondré manos a la obra lo antes que pueda, mis vacaciones empiezan el sábado   :Twisted Evil:  y es probable que no me haya dado tiempo.

Ya veremos si con un portage absolutamente contiguo y de una pieza las cosas se aceleran o no.

----------

## sirope

Gracias por sus respuestas..

Aplicaré todas las soluciones posibles, partición separada + eix-sync + ramas excluidas + scripts

Salu2

----------

## pacho2

 *Quote:*   

> 
> 
> Ese truquillo es genial, yo lo uso hace bastante tiempo y nunca me ha dado problemas (además de una partición XFS para /usr/portage   )
> 
> Saludos

 

No entiendo mucho sobre el tema, pero quizás una partición ext2 tuviese algo más de rendimiento. No creo que el jornaling fuese extrictamente necesario para /usr/portage :-/ 

Si estoy metiendo la pata, gracias por darme un poco de información  :Smile: 

Saludos

----------

## i92guboj

 *pacho2 wrote:*   

>  *Quote:*   
> 
> Ese truquillo es genial, yo lo uso hace bastante tiempo y nunca me ha dado problemas (además de una partición XFS para /usr/portage   )
> 
> Saludos 
> ...

 

Eso es exactamente lo que yo hago. Ext2 no es necesario en $PORTDIR, ni en distfiles, ni en /tmp, ni probablemente en /usr/src. Todos estos sistemas de ficheros normalmente contienen un volumen de ficheros bastante alto, y los fs's son journaling gastarían cpu de forma inútil al acceder a ellos. Por eso los formateo con ext2, y con un tamaño de bloque menor (1024), lo cual tiene dos efectos: en primer lugar permite un mayor número de i-nodos en el fs (imprescindible para portage, porque tiene una cantidad de archivos totalmente insana y sería imposible almacenar portage en una partición pequeña, no por espacio, sino porque se acabarían los i-nodos antes. En segundo lugar, se aprovecha mejor el espacio.

```

# du -sh portage/

395M    portage/

# find /var/portage/ | wc -l

133181

```

Más de ciento treinta y tres mil archivos, sería imposible meter portage en una partición de 900 megas si no fuera formateando con tamaño de bloque y de i-nodo a 1024, en lugar de 4k que es lo predeterminado.

----------

## pcmaster

 *i92guboj wrote:*   

>  *sirope wrote:*   .. ¿Por qué no mejor descargar una simple lista de ebuilds disponibles? Un emerge algo descarga el ebuild con sus medicinas y mi disco no tiene que soportar todo el árbol, sino un simple archivo de texto plano.
> 
> ¿Qué razón hay para no hacerlo de este modo?
> 
>   
> ...

 

Tienes razón, pero se podría aligerar algo el portage si al hacer un emerge --sync se bajara solamente los ebuilds y nada más, ya que actualmente se baja, además, gran cantidad de archivos adicionales, como parches, que se guardan en el directorio file de cada programa.

----------

## kropotkin

que tal funcionaria portage si en vez de usar ebuild usara una db en mysql o algo por el estilo?

----------

## ensarman

en mysql??? una aplicacion mas al Stage3??? no creo man talvez su propia base de datos cono lo hace el apt-get de debian, en una base de datos que se almacene toda la informacion de dependencias y demas.

----------

## i92guboj

 *kropotkin wrote:*   

> que tal funcionaria portage si en vez de usar ebuild usara una db en mysql o algo por el estilo?

 

Simplemente no sería portage.

Lo que comentas es imposible de realizar conservando el concepto de portage. En primer lugar, los ebuilds no son simples contenedores de información que se puedan sustituir por un registro en una base de datos. Los ebuilds son scripts, tan solo eso: scripts de bash. Y necesitan conservar su forma actual para poder ser ejecutados. Si se usara una base de datos, habría que crear un emulador de shell o algo similar que pudiera interpretar los campos de cada registro (ebuild) y ejecutar la acción correspondiente. Una pérdida de tiempo completa, en mi opinión. Algo así no se implemente de forma trivial, aunque tampoco sea especialmente difícil.

También está el tema de mysql. Un stage ya es bastante grande dependiendo de python.

Las bases de datos son la forma óptima de organizar volúmenes medianos/grandes de información, y escalan mucho mejor que un sistema de archivos, sin embargo los especiales requerimientos de portage hacen que el tiempo de acceso sea tan solo un factor más a considerar, y no el único ni el más importante.

En mi opinión, portage está muy bien como está. Si alguien es capaz de hacer algo mejor, bienvenido sea. Hay varios proyectos por ahí, como paludis. Sin embargo hay cosas bastante más importantes a las que los devs deben dedicar su tiempo que "arreglar" un sistema de paquetes que funciona perfectamente. Después de todo, comparado con las compilaciones largas, el tiempo de update de portage es el menor de los problemas, pienso yo.

----------

## luismanson

Alguien acá uso paludis? tiene muy muy buenos comentarios realmente, e incluso supera varios inconvenientes de portage...

----------

## sirope

 *Quote:*   

> Después de todo, comparado con las compilaciones largas, el tiempo de update de portage es el menor de los problemas, pienso yo.

 

Esas palabras son muy sabias, ¿A quién le importa que tarde media hora?

Portage aún tiene un largo camino, y muchas características se echan de menos.

Salu2

----------

