Discos (no gabinete usb) continuam acordando mesmo quando não estão montados

Question

Configuração

Eu tenho um compartimento USB (Buffalo DriveStation Quad) contendo quatro unidades conectadas ao meu servidor nas (servidor ubuntu 14.04). O gabinete é 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 partição única ( /mnt/part1 ) com sistema de arquivos ext4 sem journalling.

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. Uma delas é 90% da capacidade total do grupo de volume ( /mnt/part2 ) e uma que é 10% ( /mnt/part3 ). Ambos também são ext4 sem journalling.

Problemas de APM

Meus problemas começaram com os modos APM padrão, pois notei que a cabeça dos discos rígidos estacionava bastante agressivamente a cada dois minutos. Depois de pesquisar o tópico um pouco, 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.

Algum sono?

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

Desmontando todas as partições e emitindo hdparm -y /dev/sd[bcde] colocará as unidades no modo de suspensão, mas apenas por alguns minutos. Depois disso, todos acordarão um por um. Eu 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 desativar o APM com hdparm -B255 /dev/sd[bcde] e mandá-los dormir depois disso, mas a mesma coisa. Ainda assim, os drives acordam depois de alguns minutos.

Eu não tenho mdadm em execução no modo daemon (apenas uma verificação única uma vez por dia), nem deve haver mais nada sondando as unidades. Então, alguma idéia sobre o que tentar em seguida? O invólucro do Buffalo USB é apenas uma porcaria (e faz isso por conta própria)?

Atualização # 1

Demorei para o tempo que os discos demoram a despertar após a emissão de 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 / desperta os discos a cada 3 minutos. Primeiro comando para ir modo de espera só passou a ser de 40 segundos a partir do ponto de verificação.

Atualização nº 2

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

    

Answer 1

Pode ser um pouco exagerado, mas SystemTap pode ajudar você a identificar o processo que está realizando E / S nesse disco.

Prepare o 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 o ID do dispositivo que você deseja monitorar, neste caso, 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 maior número + menor (8,5) em hexadecimal. Encontre culpado. Alegra-te

[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 ~]#