Tengo una tarea semi-regular que hago en mi estación de trabajo Ubuntu 16.04: tiene un segundo disco con Windows 7. Básicamente es una instalación básica, que a veces inicio y dejo que se ejecute Windows Update. La idea es usarlo para juegos, pero bueno, resulta que rara vez tengo tiempo. Todavía lo mantengo actualizado.
Esta tarea semi-regular es clonar el disco ntfsclonedespués de realizar dicha actualización. Mírelo como una toma de instantáneas de "baja tecnología", porque, lamentablemente, Windows no puede vivir dentro de un volumen LVM. (Bueno, puede, si se está virtualizando). Escribí un script para hacer esto (y algunas cosas más), porque soy vago, pero el comando que lleva más tiempo y causa el problema es:
ntfsclone -s -o /home/jorg/Images/$(date +%F).ntfsclone /dev/sdc2
¿Dónde /dev/sdc2está la partición de Windows y /home/jorg/Images/es un volumen LVM, en un RAID1 compuesto por /dev/sday /dev/sdb. Todos estos discos son discos duros normales, conectados mediante SATA.
El problema que surge: cuando hago esto, mi estación de trabajo queda total y absolutamente inutilizable. La capacidad de respuesta es simplemente horrible. Incluso cambiar e iniciar sesión en una consola virtual ( Ctrl- Alt- F1) es insoportablemente lento.
Esto no es solo uso ntfscloney es por eso que sospecho de E/S de disco. Cuando lo hago dd, una herramienta que suelo utilizar para ayudar a las personas con discos defectuosos, sucede lo mismo. Es aún peor con dd, porque a menudo pasa por USB. Dicho esto, lo he usado dden lugar de ntfsclonecomo prueba con la configuración anterior, que es solo SATA, y es igual de malo. Sí, uso el bsparámetro in ddpara que el almacenamiento en búfer se realice correctamente.
La cuestión es que, si bien la computadora se ralentizó en 14.04, no quedó inutilizable. Era simplemente "un poco más lento", pero la navegación, el correo electrónico y el terminal aún eran soportables.
Por ahora, también he jugado con los diferentes programadores de discos. Los programadores admitidos son:
cat /sys/block/sda/queue/scheduler
noop [deadline] cfq
Cambiar a cfqo noopno ayudó. ( echo cfq > /sys/block/sda/queue/scheduler).
Alguna información sobre mi máquina:
root@tiger:~# uname -a
Linux tiger 4.4.0-34-generic #53-Ubuntu SMP Wed Jul 27 16:06:39 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
root@tiger:~# dmidecode -t baseboard | grep -e Product -e Manufacturer
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: F1A75-V PRO
root@tiger:~# free -mh
total used free shared buff/cache available
Mem: 15G 1,7G 2,9G 154M 11G 13G
Swap: 31G 0B 31G
root@tiger:~# for disk in a b c ; do echo \[ Disk informatoin for \/dev\/sd$disk \] ; hdparm -I /dev/sd$disk | grep -e Model -e Transport ; done
[ Disk informatoin for /dev/sda ]
Model Number: ST1500DL003-9VT16L
Transport: Serial, SATA Rev 3.0
* SMART Command Transport (SCT) feature set
[ Disk informatoin for /dev/sdb ]
Model Number: ST1500DL003-9VT16L
Transport: Serial, SATA Rev 3.0
* SMART Command Transport (SCT) feature set
[ Disk informatoin for /dev/sdc ]
Model Number: WDC WD1002FAEX-00Z3A0
Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6
* SMART Command Transport (SCT) feature set
Me doy cuenta de que mis /dev/sday /dev/sdbno son potencias, pero les fue bien en 14.04.
¿Alguien también está viendo un rendimiento abismal al realizar altas E/S? Si es así, ¿encontró una solución alternativa?
Respuesta1
Elnúcleo xanmodpareció ayudar. Estaba ejecutando 16.04 con unidad de arranque SSD, gnome 3.2. Pensé que el programador de fechas límite lo haría, pero no pareció ayudar mucho. Esto es lo que seguí: http://www.hecticgeek.com/2016/09/supercharge-ubuntu-16-04-lts-xanmod-kernel/