Eu tenho uma tarefa semi-regular que faço na minha estação de trabalho Ubuntu 16.04: ela tem um segundo disco com o Windows 7. Basicamente, é uma instalação simples, que às vezes inicializo e deixo o Windows Update ser executado. A ideia é usá-lo para jogos, mas, bem, raramente tenho tempo. Ainda o mantenho atualizado.
Esta tarefa semirregular é clonar o disco ntfsclonedepois de fazer essa atualização. Veja isso como um instantâneo de "baixa tecnologia", porque - infelizmente - o Windows não pode viver dentro de um volume LVM. (Bem, pode, se estiver sendo virtualizado.) Escrevi um script para fazer isso (e mais algumas coisas), porque sou preguiçoso, mas o comando que leva mais tempo e causa o problema é:
ntfsclone -s -o /home/jorg/Images/$(date +%F).ntfsclone /dev/sdc2
Onde /dev/sdc2está a partição do Windows e /home/jorg/Images/é um volume LVM, em um RAID1 composto por /dev/sdae /dev/sdb. Todos esses discos são discos rígidos normais, conectados via SATA.
O problema que surge: quando faço isso, minha estação de trabalho fica total e totalmente inutilizável. A capacidade de resposta é simplesmente horrível. Até mesmo alternar e fazer login em um console virtual ( Ctrl- Alt- F1) é insuportavelmente lento.
Isso não é apenas uso ntfsclonee é por isso que suspeito de E/S de disco. Quando faço isso dd, uma ferramenta que costumo usar para ajudar pessoas com discos defeituosos, acontece o mesmo. É ainda pior com o dd, porque isso geralmente passa pelo USB. Dito isto, usei ddem vez de ntfscloneum teste com a configuração acima, que é somente SATA, e é igualmente ruim. Sim, utilizo o bsparâmetro in ddpara que o buffer seja feito corretamente.
O problema é: embora o computador tenha ficado lento em 14.04, ele não ficou inutilizável. Era apenas "um pouco mais lento", mas a navegação, o e-mail e o terminal ainda eram suportáveis.
Até agora, também brinquei com diferentes agendadores de disco. Os agendadores suportados são:
cat /sys/block/sda/queue/scheduler
noop [deadline] cfq
Mudar para cfqou noopnão ajudou. ( echo cfq > /sys/block/sda/queue/scheduler).
Algumas informações sobre minha 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
Eu percebo que não /dev/sdasou /dev/sdbuma potência, mas eles se saíram bem em 14.04.
Alguém também está vendo um desempenho péssimo ao fazer E/S alta? Em caso afirmativo, você encontrou uma solução alternativa?
Responder1
Okernel xanmodpareceu ajudar. Eu estava executando o 16.04 com unidade de inicialização SSD, gnome 3.2. Achei que o agendador de prazos faria isso, mas não pareceu ajudar muito. Isto é o que eu segui: http://www.hecticgeek.com/2016/09/supercharge-ubuntu-16-04-lts-xanmod-kernel/