Los discos (en el gabinete usb) se despiertan incluso cuando no están montados

13

Preparar

Tengo una carcasa USB (Buffalo DriveStation Quad) que contiene cuatro unidades conectadas a mi servidor nas (servidor ubuntu 14.04). El gabinete está configurado en modo JBOD, por lo que veré todos los discos en Linux.

Dos de los discos (sdb y sdc) están configurados con raid de software como /dev/md0(raid1). Y /dev/md0se monta como una partición única ( /mnt/part1) con el sistema de archivos ext4 sin diario.

Los otros dos discos (sdd y sde) están configurados con LVM como un grupo de volúmenes, desde donde he montado dos particiones lógicas. Uno de los cuales es el 90% de la capacidad del grupo de volumen completo ( /mnt/part2), y uno que es el 10% ( /mnt/part3). Ambos también son ext4 sin diario.

Problemas de APM

Mis problemas comenzaron con los modos APM predeterminados, ya que noté que la cabeza de los discos duros se estacionaba bastante agresivamente cada dos minutos. Después de investigar el tema por un momento, terminé usando hdparm -B198 /dev/sd[bcde]. Esto parece permitir cierto nivel de ahorro de energía, pero sin realmente tener que estacionar la cabeza.

Cualquier sueño?

Estoy un poco contento con la situación actual, pero todavía me gustaría que las unidades se apaguen si no hay actividad. Especialmente los sdb y sdc ( /mnt/part1) que realmente no obtienen ninguna actividad durante el 95% del tiempo. Lo que sea que haya intentado, el problema parece ser que las unidades no duermen más de un minuto o dos.

Al desmontar todas las particiones y al emitirlas hdparm -y /dev/sd[bcde], las unidades se pondrán en modo de suspensión, pero solo durante unos minutos. Después de eso, todos se despertarán uno por uno. Intenté depurar el problema habilitando block_dump ( echo 1 > /proc/sys/vm/block_dump), pero no veo ningún acceso a los discos.

También intenté desactivar APM con hdparm -B255 /dev/sd[bcde], y les ordené que durmieran después de eso, pero lo mismo. Aún así, las unidades se despiertan después de un par de minutos.

No tengo mdadmcorriendo en modo daemon (solo una verificación una vez al día), ni debería haber algo más probando las unidades. Entonces, ¿alguna idea sobre qué probar a continuación? ¿El alojamiento USB de Buffalo es simplemente malo (y lo hace solo)?

Actualización n. ° 1

Me tomé el tiempo para cuánto tiempo tardan los discos en despertarse después de la emisión hdparm -y /dev/sd[bc]. Las siguientes marcas de tiempo ilustran el patrón:

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

Es decir, parece que algo comprueba / activa los discos cada 3 minutos. El primer comando para pasar al modo de espera resultó estar a 40 segundos del punto de control.

Actualización n. ° 2

Reinició la máquina con acpi=off apm=off. Tampoco ayudó. Por cierto, la máquina es la computadora portátil Lenovo L520. Por si alguien lo considera relevante.

hard-disk usb-drive power-management hdparm Toni
fuente
2
my $ .02: intente detener todo en su máquina (los demonios demasiado entusiastas podrían estar buscando dispositivos para sondear), use la opción de montaje noatime.
Laszlo Valko
@LaszloValko, logró reducir los procesos a upstart-{socket,file}-bridge, dhclient, getty and sshd- sin suerte :(. Por supuesto, se están ejecutando muchos procesos del kernel (los que figuran entre paréntesis). Todavía no he investigado si podría reducirlos mediante algunos parámetros del kernel ... y cuáles serían buenos candidatos.
Toni
1
Una forma sencilla de saber si es el gabinete o su sistema operativo sería desactivar las unidades y luego desconectar el USB.
Circus Cat
@qasdfdsaq, desafortunadamente esta Buffalo Drivestation viene con una función de apagado elegante. El gabinete se apaga inmediatamente cuando el cable usb está desconectado. Incluso el interruptor de encendido solo tiene las opciones "apagado" y "automático".
Toni
1
Solo una foto en la oscuridad: verifique las rutas podadas de b.conf y los montajes de enlace, para que estas rutas se omitan explícitamente (servicio 'localizar'); Sin embargo, podría ser fácilmente otro servicio similar.
michael

Respuestas:

2

Puede ser un poco exagerado, pero SystemTappodría ayudarlo a identificar qué proceso está haciendo E / S en ese disco.

Preparar SystemTap

[root@localhost ~]# stap-prep
snip

Instalar script de rastreo

[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)
}

Averigüe la identificación del dispositivo que desea monitorear, en este caso voy a monitorear / 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 ~]#

Monitoree, usando el número mayor + menor (8,5) en hexadecimal. Encuentra al culpable. Alegrarse

[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
fuente