Estou tentando descobrir o que há de errado com o meu novo disco rígido Seagate ST2000DM001 (-9YN164), se de fato alguma coisa. Irregularmente, mas aparentemente a cada poucos minutos (a cada 3-7 minutos, agora no tempo em que estive sincronizando), ele faz um som de duas partes (0,2 segundos no máximo), bastante agudo, de duas partes. Definitivamente não é normal "ruído de trabalho", e não parece haver qualquer correlação com a atividade do disco.
O mais estranho é que, quando eu estava usando a unidade com um adaptador USB-SATA (uma daquelas coisas de dongle, não um berço de plug-in), sentado em cima do gabinete do computador com um compartimento de papel para isolamento, não fez nenhum ruído incomum durante a cópia de cerca de 1 TB de dados da unidade interna (que estava mostrando sinais de começar a falhar, inclusive relatando erros de leitura incorrigíveis durante uma varredura do sistema de arquivos de rotina). A mudança depois disso foi que eu removi a unidade interna antiga, a substituí pela nova e reinstalei os cabos de dados e energia SATA.
Eu usei o GSmartControl, que apresenta dados smartctl (estou executando Debian 6.0 neste sistema) para inspecionar os dados SMART da unidade, prestando especial atenção à Contagem de Início / Parada (mostrada como: valor norma 100, pior 100 , limite 20, valor bruto 5), taxa de erro de pesquisa (66, 65, 30, 3981634) e Contagem de novas tentativas de spin-up (100, 100, 97, 0) (spin-up intermitente ou erros de busca foi minha primeira hipótese, mas os dados parecem não suportá-la). Nenhum desses valores parece estar mudando, e tudo (pré-falha e velhice) diz que falhou "nunca", que IMO é esperado em uma unidade que só está em serviço há alguns dias. O valor bruto da taxa de erro de busca parece alto, mas, a menos que esteja crescendo rapidamente, não vejo isso como uma grande preocupação. Usando a mesma ferramenta, também executei o transporte e os autotestes curtos, os quais foram concluídos sem erros e mostram um valor de 41 horas no log de teste. No momento, estou executando um autoteste de unidade estendido (incluindo uma varredura de superfície de disco), mas, francamente, não acho que isso atrairá algo de muito interesse. Uma coisa que certamente é interessante, no entanto, é que em pouco mais de 15 minutos, agora que o autoteste estendido foi executado, eu não ouvi nenhum barulho assim, o que, se nada mais , aponta ainda para algo sobre a nova unidade sendo o culpado (eu não tenho feito nada diferente neste tempo).
Usando o hdparm, desativei a economia de energia em como root executando hdparm -S 0 /dev/sda (onde /dev/sda é a unidade em questão). Isso não teve efeito aparente.
Qualquer ideia seria apreciada.
EDITAR: Seguindo a sugestão de @totaam, desliguei o computador completamente (incluindo o interruptor principal na parte traseira da PSU), depois reiniciei e gradualmente adicionei complexidade. Tudo estava bem, tanto quanto eu poderia dizer através do nível de execução 1, mas no nível de execução 2 (que no Debian é multiusuário com X, então basicamente a pia da cozinha foi lançada neste momento) a unidade começou a exibir o mesmo comportamento novamente. Então, olhei para o que foi iniciado ao entrar no nível de execução 2, procurando por possíveis culpados e encontrei acpid como um candidato claro. Desabilitar isso, no entanto, não parece ter ajudado, mesmo depois de re-executar hdparm manualmente. Vou dar uma olhada nas configurações da BIOS também, mas enquanto isso, aqui está uma lista do que começou a entrar no runlevel 2, em ordem; Alguém mais vê algum possível culpado? (E a taxa de erro de busca ainda está subindo, agora até o valor bruto 4008400).
- statd
- rsyslogd
- binfmt-support
- acpid (agora removido)
- virtualbox-ose (módulos do kernel do host)
- timidez
- dbus
- hald
- anacron
- atd
- gdm
- avahi-daemon
- cron
- cupsd
- kerneloops
- cpufreq
- ntpd
- postfix
- sshd