Desde que eu tenho o meu SSD (Crucial M4 - 256GB) eu tive um problema que ele iria escrever tão lento quanto rodar o Windows 7 em um 486 sempre que ele está fazendo algo com arquivos pequenos. Consegui "consertar" isso no Windows 7 instalando o driver / serviço da Intel Rapid Storage Technology.
No entanto, no Linux (rodando o Ubuntu 13.04) não parece haver um driver para isso. Eu tenho tentado muitas soluções diferentes e nenhuma delas parece ter funcionado até agora.
Meu SSD é particionado em uma única partição EXT4, montada como /.
Eu tenho um disco rígido de 2 TB separado que eu montei em / home
Aqui estão algumas informações que eu peguei sobre os tamanhos dos blocos:
# sudo blockdev --getbsz /dev/sda
> 4096
# sudo hdparm -I /dev/sda | grep -i physical
> Physical Sector size: 512 bytes
Minha entrada fstab para meu SSD é assim:
UUID=c954288b-e1bd-4d3b-93ab-6a688210d070 / ext4 errors=remount-ro,relatime,barrier=0,noatime,nodiratime,discard,commit=120 0 1
Como você pode ver pelas opções, eu tentei muitas coisas, mas nenhuma delas parece funcionar corretamente. Para dar um exemplo: a instalação do ViM usando o "apt-get install vim" levou mais de 2 minutos.
Um upgrade completo do apt-get levou mais de 4 horas e meia. Eu tenho rodado o Ubuntu no meu disco rígido normal (5200 rpm) e ele é muito mais rápido do que isso.
De acordo com parted, minha partição está alinhada corretamente. Eu verifiquei usando os seguintes comandos:
# sudo parted /dev/sda
<parted> align-check opt
partition: 1
> aligned 1
Além disso, ao executar o iotop sempre que o SSD fica "ocupado", vejo o jbd2 sem parar consumindo cerca de 99 ~ 100% do tempo.
Se alguém pudesse dar uma luz sobre esse assunto, seria totalmente incrível!
edit: Algumas informações adicionais:
A execução de hdparm -t / dev / sda fornece a seguinte saída (que parece totalmente boa para mim)
Timing buffered disk reads: 680 MB in 3.01 seconds = 226.16 MB/sec
Saída iotop quando inativa:
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
2346 be/4 harold 0.00 B/s 31.04 K/s 0.00 % 0.00 % chrome
1 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % init
2 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kthreadd]
3 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/0]
5 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/0:0H]
7 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/u:0H]
Às vezes, ao executar instalações de aplicativos ou outras coisas pesadas, esse processo "jbd2" entra em ação consumindo todos os recursos, enquanto o aplicativo em execução (por exemplo, atualizando algumas coisas relacionadas ao banco de dados ou instalando ou atualizando software) em torno de 3 ~ 4%)
A parte estranha é que, às vezes, está funcionando bem (tentei reproduzir o problema para postar os resultados aqui, mas com bastante rapidez está acontecendo em momentos aleatórios). Vou atualizar a saída do iotop abaixo com os resultados de quando está errado novamente.
Sinto que meu computador está me atacando agora: (
edit2: Esqueceu de adicionar alguns extras (obrigado Craig Watson)
O conteúdo do meu arquivo /etc/rc.local tem esta aparência:
echo deadline > /sys/block/sda/queue/scheduler
fstrim -v /
exit 0
E dentro de / etc / default / grub, tenho:
GRUB_CMDLINE_LINUX_DEFAULT="elevator=deadline"
Depois de tentar o agendador pela primeira vez, adicionei a parte fstrim também porque ainda não obtive bons resultados com apenas o agendador.
Obrigado antecipadamente.
Harold.