Os discos (no compartimento USB) continuam acordando mesmo quando não estão montados

13

Configuração

Eu tenho um gabinete USB (Buffalo DriveStation Quad) contendo quatro unidades conectadas ao meu servidor nas (servidor ubuntu 14.04). O gabinete está configurado para o modo JBOD, então vou ver todos os discos no Linux.

Dois dos discos (sdb e sdc) são configurados com raid de software como /dev/md0(raid1). E /dev/md0é montado como uma única partição ( /mnt/part1) com o sistema de arquivos ext4 sem o diário.

Os outros dois discos (sdd e sde) são configurados com o LVM como um grupo de volumes, de onde montei duas partições lógicas. Um deles é 90% da capacidade do grupo de volumes inteiros ( /mnt/part2) e 10% ( /mnt/part3). Ambos também são ext4 sem diário.

Problemas de APM

Meus problemas começaram com os modos padrão do APM, pois notei que a cabeça dos discos rígidos estacionava bastante agressivamente a cada dois minutos. Depois de pesquisar um pouco o assunto, acabei usando hdparm -B198 /dev/sd[bcde]. Isso parece permitir algum nível de economia de energia, mas sem realmente fazer qualquer estacionamento na cabeça.

Dormiu?

Estou meio que feliz com a situação atual, mas ainda assim gostaria que as unidades dormissem se não houvesse atividade. Especialmente o sdb e sdc ( /mnt/part1) que realmente não realizam nenhuma atividade por 95% do tempo. O que quer que eu tenha tentado, o problema parece ser que as unidades não dormem mais que um minuto ou dois.

Desmontar todas as partições e emitir hdparm -y /dev/sd[bcde]colocará as unidades no modo de suspensão, mas apenas por alguns minutos. Depois disso, todos eles acordarão um por um. Tentei depurar o problema ativando block_dump ( echo 1 > /proc/sys/vm/block_dump), mas não vejo nenhum acesso aos discos.

Eu também tentei desabilitar o APM com hdparm -B255 /dev/sd[bcde]e comandá-los a dormir depois disso, mas a mesma coisa. Ainda assim, as unidades acordam após alguns minutos.

Não estou mdadmexecutando no modo daemon (apenas uma única verificação uma vez por dia), nem deve haver mais nada investigando as unidades. Então, alguma idéia sobre o que tentar a seguir? O gabinete USB Buffalo é apenas uma porcaria (e faz isso por conta própria)?

Atualização # 1

Demorei o tempo necessário para os discos serem ativados após a emissão hdparm -y /dev/sd[bc]. Os timestamps a seguir ilustram o padrão:

00:00 hdparm -y /dev/sd[bc]
00:40 disks start to wake up
00:59 disks fully awake
01:00 hdparm -y /dev/sd[bc]
03:40 disks start to wake up
03:59 disks fully awake
04:00 hdparm -y /dev/sd[bc]
06:40 disks start to wake up
06:59 disks fully awake

Ou seja, parece que algo verifica / ativa os discos a cada 3 minutos. O primeiro comando para entrar no modo de espera passou a ser 40 segundos a partir do ponto de verificação.

Atualização # 2

Reinicie a máquina com acpi=off apm=off. Também não ajudou. BTW, a máquina é laptop Lenovo L520. Apenas no caso de alguém achar isso relevante.

hard-disk usb-drive power-management hdparm Toni
fonte
2
meu $ .02: tente parar tudo em sua máquina (daemons com excesso de zelo podem estar olhando em volta para investigar dispositivos), use a opção de montagem noatime.
Laszlo Valko
@LaszloValko, conseguiu reduzir os processos para upstart-{socket,file}-bridge, dhclient, getty and sshd- sem sorte :(. É claro que existem muitos processos do kernel em execução (os listados entre parênteses). Ainda não investiguei se eu poderia reduzi-los por alguns parâmetros do kernel ... e quais seriam bons candidatos.
Toni
1
Uma maneira simples de saber se é o gabinete ou o sistema operacional seria diminuir as unidades e desconectar o USB.
Circus Cat
@qasdfdsaq, infelizmente, este Buffalo Drivestation vem com algum recurso sofisticado de desligamento. O gabinete se desliga imediatamente quando o cabo USB é desconectado. Até o interruptor liga / desliga possui apenas as opções "off" e "auto".
Toni
1
Apenas um tiro no escuro: verifique os caminhos removidos e as montagens de bind do updatedb.conf, para que esses caminhos sejam explicitamente ignorados (serviço de 'localização'); poderia facilmente ser outro serviço semelhante.
michael

Respostas:

2

Pode ser um pouco exagerado, mas SystemTappode ajudar a identificar qual processo está executando a E / S nesse disco.

Preparar SystemTap

[root@localhost ~]# stap-prep
snip

Instalar script de rastreamento

[root@localhost ~]# cat >/tmp/traceio2.stp
#! /usr/bin/env stap
global device_of_interest

probe begin {
  /* The following is not the most efficient way to do this.
      One could directly put the result of usrdev2kerndev()
      into device_of_interest.  However, want to test out
      the other device functions */
  dev = usrdev2kerndev($1)
  device_of_interest = MKDEV(MAJOR(dev), MINOR(dev))
}

probe vfs.write, vfs.read
{
  if (dev == device_of_interest)
        printf ("%s(%d) %s 0x%x\n",
            execname(), pid(), ppfunc(), dev)
}

Descobrir a identificação do dispositivo que você deseja monitorar, neste caso, eu vou monitorar / dev / sda5

[root@localhost ~]#  df -k /
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda5       18141508 16293424    903496  95% /
[root@localhost ~]# ls -l /dev/sda5
brw-rw----. 1 root disk 8, 5 Jul  1 01:21 /dev/sda5
[root@localhost ~]#

Monitor, usando o número maior + o menor (8,5) em hexadecimal. Encontre o culpado. Alegrar

[root@localhost ~]# /tmp/traceio2.stp 0x805
accounts-daemon(434) vfs_read 0x800005
accounts-daemon(434) vfs_read 0x800005
accounts-daemon(434) vfs_read 0x800005
lightdm(503) vfs_write 0x800005
bash(3036) vfs_read 0x800005
bash(3036) vfs_read 0x800005
^C
[root@localhost ~]#
Steve
fonte