# [aMule] Uso intensivo y constante del disco duro (cerrado)

## Yoshi Assim

¡Hola!:

Tengo un "problemilla" con aMule en mi Gentoo   :Sad:   y despúes de buscar por los foros no encuentro ninguna pista o explicación.   :Sad: 

He instalado Gentoo hace 15 días en mi portátil en un disco duro de 160 Gb. Compilé el núcleo gentoo-sources "2.6.21-gentoo-r4" y reconoce todo el hard correctamente (Asumo que en este apartado todo está OK).   :Smile: 

Particioné el disco duro de la siguiente forma:

```

gentoo ~ # fdisk -l /dev/hda

Disco /dev/hda: 160.0 GB, 160041885696 bytes

255 cabezas, 63 sectores/pista, 19457 cilindros

Unidades = cilindros de 16065 * 512 = 8225280 bytes

Disposit. Inicio    Comienzo      Fin      Bloques  Id  Sistema

/dev/hda1               1          14      112423+  83  Linux

/dev/hda2              15          78      514080   82  Linux swap / Solaris

/dev/hda3              79       19457   155661817+  83  Linux

gentoo ~ #

```

Este es mi /etc/fstab. Como podéis comprobar los sistemas de ficheros son xfs:

```

# <fs>                  <mountpoint>    <type>          <opts>                          <dump/pass>

/dev/hda1               /boot           xfs             noauto,noatime,nodiratime,logbufs=8     1 2

/dev/hda3               /               xfs             noatime,nodiratime,logbufs=8            0 1

/dev/hda2               none            swap            sw                              0 0

/dev/cdrom              /mnt/cdrom      audo            noauto,ro                       0 0

/dev/fd0                /mnt/floppy     auto            noauto                          0 0

shm                     /dev/shm        tmpfs           nodev,nosuid,noexec             0 0

```

Mi portátil tiene 512MB de RAM y no hace "swapping" apenas por lo que no creo que sea esta la causa, pero...

... Mientras aMule está funcionando el disco duro no para de "rular"   :Shocked:   :Shocked:   :Shocked:   :Sad:   :Sad:   :Sad:   ... lo he comprobado... solo pasa con aMule aMule...

Tengo activado el hdparm en el inicio y (creo) que correctamente configurado...   :Smile: 

```

# /etc/conf.d/hdparm: config file for /etc/init.d/hdparm

# You can either set hdparm arguments for each drive using hdX_args,

# discX_args, cdromX_args and genericX_args, e.g.

#

# hda_args="-d1 -X66"

#disc1_args="-d1 -c1 -m16 -A1 -u1 -a64 -X69"

#cdrom0_args="-d1 -c1"

# or you can set options for all PATA drives

pata_all_args="-d1 -c3 -u1 -a256 -X69"

# or you can set options for all SATA drives

#sata_all_args=""

# or, you can set hdparm options for all drives

#all_args=""

```

Tengo otro disco duro con una instalación de Ubuntu 7.04... lo que pasa que las particiones son ext3 para /boot y reiserfs para /... Aquí el disco duro funciona como es de esperar...   :Smile: 

No me atrevo a dejar Gentoo con aMule funcionando porque tengo miedo de quemar el disco duro   :Sad:  ... sólo se me ocurre que xfs y aMule no se llevan bien...

¿ Alguien en el foro que use aMule con xfs que me pueda dar su opinión ?

¡ Grácias ! y hasta pronto

EDITADO: Modificada la configuración de /etc/conf.d/hdparm, la que se indicaba primero era incorrecta y "sólo funcionaba a medias"Last edited by Yoshi Assim on Sun Aug 26, 2007 4:04 pm; edited 4 times in total

----------

## Yoshi Assim

¡ hola !

He probado a cambiar opciones de montaje de /etc/fstab y lo he dejado así:

```
 

/dev/hda1      /boot      xfs      noauto,noatime,nodiratime   1 2

/dev/hda3      /      xfs      noatime,nodiratime,logbufs=8,logbsize=256k      0 1

/dev/hda2      none      swap      sw            0 0

/dev/cdrom      /mnt/cdrom   audo      noauto,ro         0 0

/dev/fd0       /mnt/floppy   auto      noauto            0 0

shm         /dev/shm   tmpfs      nodev,nosuid,noexec      0 0

```

He cambiado la prioridad de ejecución de amule con renice y nada ha cambiado   :Sad:   :Sad:   :Sad:  .

También he comprobado la partición  con xfs_check para ver si tenía errores y los he corregido con xfs_repair... He tenido que arrancar desde el CD de Instalación...

¿ Alguna idea ?   :Idea:  ,  ¿ alguna pista ?   :Question: 

----------

## i92guboj

aMule, mlnet y similares descargan contínuamente, y contínuamente, necesitan acceder al disco para ir guardando lo que se descarga. Todo dependerá del programa en cuestión, y todo depende también de lo que tú consideres que es demasiada actividad.

Un parpadeo leve a intervalos de 1 o 2 segundos no es raro si estás usando p2p. Sea cual sea el programa que se use. A nivel de sistema de ficheros, con ext3, por ejemplo, -o async, la opción por defecto, escribe de forma diferida a disco, lo cual quiere decir que las cosas no se graban necesariamente cuando tú lo dices, sino que se graban en bloques, cuando se considera oportuno. La opción sync, por contra, hace que todo se grabe de forma síncrona, lo cual es buena idea en disquetes y pen drives, pero no en discos duros, a no ser que la seguridad sea un factor clave.

No tengo información sobre xfs, no se si dispone de algo similar.

En cualquier caso, el disco duro de un ordenador que se somete contínuamente al estrés del p2p, no va a tener un promedio de vida especialmente largo, porque el disco duro va a estar encendido 24/7. Aunque las operaciones se realicen cado pocos segundos, el disco tiene que estar rotando y activo todo el tiempo, ya que el tiempo para que el disco para y arranque es inménsamente mayor. El único consejo que te puedo dar es que busques una máquina barata, antigua, y la uses exclusivamente para p2p.

----------

## Yoshi Assim

¡Hola i92guboj!

He mirado la documentación que se adjunta con el kernel sobre xfs y no aparece la opción async  :Sad: 

Entiendo lo que me dices de sobre los programas p2p y los accesos a disco... pero hace tiempo que los uso y nunca he tenido un accesso a disco tan intenso como ahora... Casi parece que esté continuamente haciendo un "hashing" de algún fichero...   :Shocked: 

Hay algo que me llama tremendamente la atención y es:

```
gentoo ~ # free

             total       used       free     shared    buffers     cached

Mem:        515652     506760       8892          0        152     309244

-/+ buffers/cache:     197364     318288

Swap:       514072          0     514072

```

Si te fijas el tamaño de los buffers es muy pequeño... Esto lo comprobado también recién iniciado el sistema sin el aMule funcionando y su valor era muy bajo (casi idéntico)...

Esto me lleva a varias preguntas... ¿Tiene algo que ver el tamaño de los búffers?.... ¿Hay algún parámetro del núcleo que se pueda "tocar"?... ¿Es un problema con xfs?... ¿Pasaría lo mismo con otros filesystems?

De todas formas... cuando hago pruebas con Ubuntu la actividad de disco no es la misma ni de lejos  :Exclamation: 

----------

## i92guboj

Bueno, como ya te digo, no puedo hablar desde la experiencia, porque solo he usado este sistema de ficheros de forma temporal. Hay algunas cosas de él que no me convencieron. Pero eso es otro tema.

Mirando entre las opciones no veo nada que me parezca un equivalente inmediato al async the ext3. Tampoco se si ese comportamiento es predeterminado para xfs, así que a lo mejor ni siquiera es eso. Yo probaría a crear una pequeña partición ext3 y decirle a aMule que guarde ahí, para ver si el acceso a disco es igual de persistente.

EDIT, como ya digo, no se mucho de xfs, pero el hecho de que no tengas memoria reservada para buffers mientras estás trabajando, quiere decir con casi toda seguridad que todo se vuelca al disco en modo síncrono, lo cual apoyaría mi teoría. No se si ese comportamiento de xfs se puede cambiar o no (y repito que tampoco estoy seguro de que ese sea el problema, solo digo que los indicios que hay son compatibles con esa teoría).

----------

## kabutor

xfs no parece lo mas apropiado para esa utilidad que tu le das, que yo sepa xfs es para escribir rapidamente ficheros de tamaño muy grande, muy rapido, y q no te importe que se te vaya todo al garete en un apagon.

Hablamos de edicion de video y temas similares donde vas a escribir un par de gigas en 10 minutos.

----------

## elsdello

Hola buenas,

como te dicen anteriormente yo lo primero que haria es migran a otro sistema de ficheros, a mi el ext3 me parece muy robusto, además de desfragmentarse poco y ser un sistema seguro con journaling (creo que se llama asi).

Ya que por lo que veo tu disco duro es de 160GB coge y haz una particion para probar de 30GB y montas el directorio temp del amule y el incoming alla. 

Si es culpa del sistema de ficheros tendrias ya que notar mejoria en ese campo.

Luego sobre el hdparm yo para referirme al disco duro me referi a el como hda_args, supongo que la forma con la que te refieres tu tambien es correcta ya que en el comentario pone que te puedes referir a el asi.

Por ultimo darte este link que explica como configurar correctamente el hdparm

http://es.gentoo-wiki.com/HOWTO_Hdparm

Suerte.

----------

## pcmaster

Si acabas de instalar amule y lo has ejecutado por primera vez, es posible que esa actividad se deba a que está calculando los hash de los archivos compartidos que hayas puesto.

----------

## Yoshi Assim

Durante la instalación escogí xfs en detrimento de ReiserFs porque leí varios posts en el foro que lo recomendaban por tener, actualmente, el mejor rendimiento...

En este post (lo buscaré y lo añadiré aquí), se hacian varias comparaciones y pruebas de rendimiento y fiabilidad que lo daban como ganador por encima de ext3 con journaling y por encima de ReiserFs...

Desde que en la instalación de Gentoo se recomendaba reiserfs como sistema de ficheros (hace ya algunos años), lo he estado utilizando sin ningún problema... y nunca perdí ni un solo archivo...

Si no es ningún parámetro del kernel que se pueda/deba "tunear"... (me llama la atención que la memoria reservada para los buffers sean tan poca).

Creo que me voy a ver obligado a hacer una copia de seguridad y volver a particionar el disco duro... ¡¡¡vamos un curro!!!   :Sad:   :Sad:   :Sad: Last edited by Yoshi Assim on Thu Aug 23, 2007 4:54 pm; edited 1 time in total

----------

## i92guboj

 *Yoshi Assim wrote:*   

> Durante la instalación escogí xfs en detrimento de ReiserFs porque leí varios posts en el foro que lo recomendaban por tener, actualmente, el mejor rendimiento...

 

Lo del rendimiento es muy relativo, depende de quién lo mida, como lo mida, y de la situación general. Las opciones de montaje influyen de forma tremendísima, prueba ext3 con noatime,data=writeback y con tune2fs -O dir_index

 *Quote:*   

> 
> 
> En este post (lo buscaré y lo añadiré aquí), se hacian varias comparaciones y pruebas de rendimiento y fiabilidad que lo daban como ganador por encima de ext3 con journaling y por encima de ReiserFs...
> 
> 

 

Totalmente irrelevante. Encontrarás lo que busques, así es la naturaleza humana. De esos benchmarks no hago ni caso ya.

Puedes encontrar otros que den por ganador a ext3, y otros que den por ganador a reiser4 o reiserfs, tan solo es cuestión de echar el tiempo suficiente hasta que la realidad se adapte a lo que tu quieres. Así de sencillo. La cruda realidad es que ningún sistema de ficheros es más rápido en todos los campos. Y desde luego ninguno va a convertir tu máquina en una supermáquina.

En cuanto a fiabilidad, xfs no puede ser el mejor, en la vida, por la sencilla razón de que es un sistema que no hace chequeos, y que es conocido por perder datos como ninguno si hay apagones. Tienes qeu correr los checks manualmente, y si te olvidas, y el disco está inconsistente, se puede ir todo el fs a la porra. Si eso es fiabilidad, que me lo expliquen. Aparte de eso, y al margen de las experiencias personales de cada uno, el único sistema fiable, si es que hay alguno, es ext3, porque es nativo de linux, no un port como todos los demás, y su historia global lo demuestra, al margen de que para algunos haya fallado 50 veces.

En cualquier caso, suerte con ese particionado, a ver si vemos algo de luz jeje  :Smile: 

----------

## Yoshi Assim

¡ Me rindo !   :Crying or Very sad: 

No tengo ganas de perder maś tiempo (ni que lo perdáis vosotros). Voy a reparticionar el hd ahora mismito...   :Sad:   :Sad: 

Ahora cerraré este hilo.

¡ Gracias a todos !   :Very Happy: 

----------

## i92guboj

 *Yoshi Assim wrote:*   

> ¡ Me rindo !  
> 
> No tengo ganas de perder maś tiempo (ni que lo perdáis vosotros). Voy a reparticionar el hd ahora mismito...   
> 
> Ahora cerraré este hilo.
> ...

 

Como dije más arriba, yo probaría primero en una pequeña partición ext3.

No vaya a ser que reparticiones, y encuentres el mismo problema.

----------

## Yoshi Assim

 *i92guboj wrote:*   

>  *Yoshi Assim wrote:*   ¡ Me rindo !  
> 
> No tengo ganas de perder maś tiempo (ni que lo perdáis vosotros). Voy a reparticionar el hd ahora mismito...   
> 
> Ahora cerraré este hilo.
> ...

 

¡¡¡ Hey !!!... Me ha dado guerra... pero ya está...

Todo funciona OK   :Smile:   :Smile:   :Smile:  ... Un uso del disco muy bajo (como tiene que ser)... 

Pero... ¿puedo hacerte una última pregunta sobre un "temilla" de ext3 que no me ha quedado muy claro?...   :Question: 

... Ahora tengo montadas las particiones ext3 con las opciones noatime,nodiratime,async,data=journal en /etc/fstab...

Mi pregunta(s) es la siguiente:   :Idea:   :Idea:   :Idea: 

¿Puedo cambiar la forma de hacer "journaling" de cualquier partición con sólo modificar sus opciones en el /etc/fstab? o tengo que pasar el e2fsck o el tune2fs después de modificar fstab...   :Question: 

¿Es necesaria la opción "async" (como uso un portátil no es que me preocupen mucho los cortes de energía eléctrica...  Además no vivo en Barcelona   :Evil or Very Mad:   :Very Happy:   jajaja)?   :Question:  

----------

## i92guboj

 *Yoshi Assim wrote:*   

> 
> 
> ... Ahora tengo montadas las particiones ext3 con las opciones noatime,nodiratime,async,data=journal en /etc/fstab...
> 
> Mi pregunta(s) es la siguiente:    
> ...

 

No es necesario hacerlo. La opción journal toma efecto al montar la unidad.

 *Quote:*   

> 
> 
> ¿Es necesaria la opción "async" (como uso un portátil no es que me preocupen mucho los cortes de energía eléctrica...  Además no vivo en Barcelona     jajaja)?   

 

La opción async es el comportamiento predeterminado, hasta donde yo sé. La contraria, sync, es más aconsejable en medios removibles. Aunque también los puedes montar con async si quieres. Tan solo, asegúrate de hacer un sync manual o desmontar la unidad correctamente antes de extraer el disco o el pen drive.

----------

