martes, 7 de febrero de 2012

Fedora, cpulimit y discos NTFS

Debido a mis problemas con los discos NTFS decidí seguir los consejos de hckorootx (véase comentarios aquí). Esto nos lleva a algunos problemas. El primero, cpulimit no esta en los repositorios estándar de Fedora, así que nos queda instalarlo desde un paquete rpm (32 bits o 64 bits), o bien introducir el repositorio sphere. Por ejemplo, la forma más fácil es como administrador
$ su -
     palabrita de administrador
# gedit

en ese documento pegamos el texto que podemos extraer de esos enlaces

[rpm-sphere]
name=RPM Sphere
baseurl=http://download.opensuse.org/repositories/home:/zhonghuaren/Fedora_16/
gpgkey=http://download.opensuse.org/repositories/home:/zhonghuaren/Fedora_16/repodata/repomd.xml.key
enabled=1
gpgcheck=1


y luego lo guardamos en el directorio de los repositorios (/etc/yum.repos.d) como rpm-sphere.repo.

Actualizamos (nos basta un simple # yum update y ya se recargan los repositorios) y lo instalamos directamente

# yum install cpulimit

Sin embargo surgen nuevas dudas a partir de aquí. Si nos fijamos en los comentarios de hckoroot, la forma más fácil de usar cpulimit es, en vez de identificar el comando a controlar por su PID, lo mejor es identificarlo por su nombre. Nos quedaría

cpulimit --path=/ruta/ejecutable --limit=N

lo que nos lleva a como copiamos:

- Si usamos cp en terminal, el comando es cp, claro


- Si usamos rsync, que a mi me gusta particulamente, el comando es rsync



El problema radica en que la mayor parte copiará con Nautilus, que lleva embebido los comandos, y no genera una nueva instancia para copiar, si no que todo lo que hagamos con Nautilus se hace dentro de la misma instancia. A eso se suma que el gran consumo del sistema al copiar en discos NTFS se produce no en la copia, si no en el propio manejo del NTFS a través de mount.ntfs. Por ejemplo este top copiando con Nautilus en un disco formateado NTFS:


Y si a ello le sumamos otras aplicaciones que consuman recursos, por ejemplo Chromium y aMule, llegamos al bloqueo del sistema


¿Podemos solucionarlo con cpulimit? Desde mi punto de vista no. Si el límite que le ponemos es sobrepasado, la aplicación deja de funcionar; si de corta mount.ntfs, probablemente perderemos el contenido que hayamos copiado en él, ya que no se guardarán las nuevas tablas, como ya me ha pasado a mi sin incluir cpulimit. Además, ¿cuál sería el límite? Como se puede ver en esa instancia, mount.ntfs estaba momentáneamente por encima de 50%; probablemente esté a veces por debajo y otras veces por arriba. Si llegamos hasta un 70%, ¿cuanto queda para lo demás?
Conclusión: una única recomendación para copiar en discos formateados en NTFS en Linux - paciencia y nunca hacer saltar el sistema. Mejor esperar. Un segundo apunte, que me aplico en estos momentos, copiar en lotes pequeños, como mucho 30-40GB, por que la paciencia tiene un límite y tendemos a ponernos nerviosos.
Si alguien quiere probar cpulimit en la copia sobre NTFS, que lo haga y nos diga que límite hay que poner. Yo prefiero aplicar la paciencia y no perder más material.

2 comentarios:

  1. Prueba a añadir los parámetros "pci=routeirq" y "elevator=noop" al final de la línea de carga del kernel en /boot/grub/grub.cfg, es decir:

    linux /boot/vmlinuz...pci=routeirq elevator=noop

    ResponderEliminar
  2. No lo tengo claro. El uso de pci=routeirq supone que el bus del USB no ha sido bien ruteado y que puede tener un driver equivocado (USB 1.1?). Sin embargo no es así, por que la velocidad de copia en mi caso es correcta; no se produce la famosa caída de velocidad de copia hasta los 0.8-1.1MB/s en puertos USB de Linux. Por ejemplo, hoy he copiado 52Gb con 62 ficheros a una velocidad media final de 30MB/s. El problema está en el gran consumo de recursos.
    Podría quizá, pero solo quizás, el No Op del elevator, anulando cualquier mejora de la entrada/salida, por si hay algo que está, en el intento de mejora de la copia, ocupando "sitio". Sin embargo he leído en algunos foros que se puesiera pci=routeirq elevator=as.
    No sé; los problemas de los USB y NTFS parecen ser muchos bugs, y no solo uno, y cada persona encuentra soluciones para sus equipos que no siempre valen para los demás. Ayer he estado buceando por la red y creo que he visto al menos 20 soluciones diferentes; unas son similares a las que comentas, y otras supones en desmontado del montaje automático más un montaje manual, controlando la velocidad que aparece como posible en el dispositivo para ver si ha cargado como 1.1 o como 2. Sin embargo, este no es realmente "mi" problema. Por ahora lo estoy resolviendo con copias parciales, con bloques de 5-50GB, y nunca mandar copias masivas. Sin embargo ahora me he comprado un disco nuevo Black Caviar para hacer mi copia de seguridad. Según dicen es un dispendio, que esos son discos de sistema, no de copia, pero el MyBook es muy lento para mi gusto. Cuando doy la orden rsync sobre un disco vacio (primera copia), la salvación completa de mi historial de trabajo suma 800GB (550GB de trabajo y el resto de música y unos multimedia, que la incluyo en la copia de seguridad), a si que me lo temo.

    ResponderEliminar