-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Hola:

(esta es para Rafa ;-) )

Llevo como un año mosqueado por un problema al intentar hibernar mi
ordenador. Normalmente funciona perfecto, pero a veces se queda pillado y
no progresa (y puedo arrancar programas tal cual). En esas ocasiones
intento apagar el ordenador, y también se queda pillado. Incluso hago
ctrl-alt-supr como 10 veces rápidamente: el kernel lo detecta y dice que
ha detectado esas teclas siete veces en rápida sucesión, que entiende que
es una emergencia y que actúa, pero no, no actúa. Tengo que dar el gran
botonazo, y al día siguiente un gran fsck.

Hace poco puse "atop" en un terminal, y ví (cuando se trababa la
hibernación) que decía que el disco sdc estaba al 100% ocupado. Iotop
también pone algo interesante:

iotop:

Total DISK READ :       0.00 B/s | Total DISK WRITE :     368.01 K/s
Actual DISK READ:       0.00 B/s | Actual DISK WRITE:     269.56 K/s
   TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
25530 be/4 root        0.00 B/s  332.85 K/s  0.00 % 97.58 % [kworker/u64:1+flush-8:32]  <==
25104 be/4 root        0.00 B/s    4.69 K/s  0.00 %  1.41 % [kworker/8:1-events]
  1408 be/3 root        0.00 B/s   11.72 K/s  0.00 %  1.25 % [jbd2/sdc10-8]
25944 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.04 % [kworker/0:2-events]
25637 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.04 % [kworker/0:0-events]
11191 be/4 cer         0.00 B/s   18.75 K/s  0.00 %  0.00 % firefox -P Small [localStorage DB]

atop:

PRC |  sys    0.84s   |  user   1.73s   |  #proc    625  |   #zombie    1  |   no  procacct  |
CPU |  sys      10%   |  user     29%   |  irq       1%  |   idle   1065%  |   wait     96%  |
CPL |  avg1    0.86   |  avg5    0.45   |  avg15   0.41  |   csw   102167  |   intr   58821  |
MEM |  tot    31.3G   |  free   13.2G   |  cache   2.8G  |   buff    1.4G  |   slab    1.2G  |
SWP |  tot   100.0G   |  free   94.8G   |                |   vmcom  29.4G  |   vmlim 115.7G  |
LVM |     cr_cripta   |  busy      1%   |  read       0  |   write      2  |   avio 34.0 ms  |
DSK |           sdc   |  busy     99%   |  read       0  |   write    399  |   avio 24.9 ms  | <==
NET |  transport      |  tcpi      11   |  tcpo      17  |   udpi       0  |   udpo       0  |
NET |  network        |  ipi       12   |  ipo       17  |   ipfrw      0  |   deliv     12  |
NET |  eth0      0%   |  pcki      13   |  pcko      18  |   si    1 Kbps  |   so    1 Kbps  |



   PID SYSCPU USRCPU  VGROW  RGROW  RUID     EUID     ST EXC   THR S CPUNR
CPU  CMD        1/6
10990  0.06s  0.22s     0K   172K  cer      cer      --   -    64 S     7   3%  Web Content
10799  0.08s  0.19s     0K     0K  cer      cer      --   -    81 S     5   3%  firefox
11012  0.02s  0.23s     0K   -84K  cer      cer      --   -    60 S     8   2%  Web Content
  9585  0.03s  0.20s     0K     0K  root     root     --   -     1 S     0   2%  iotop
11096  0.04s  0.18s  1024K  1784K  cer      cer      --   -    58 S     2   2%  Web Content
  4288  0.19s  0.00s 14356K     0K  root     root     --   -    21 S     3   2%  X


Lo siguiente era ver que partición de sdc era la ocupada; eso lo descubrí
con gkrellm. Está escribiendo como 400K/S mantenidos, en la partición nueve.

/dev/sdc9 es reiserfs, y tiene varios montajes "bind":

   /dev/sdc9 on /data/Lareiserfs type reiserfs (rw,relatime,lazytime,user_xattr,acl)

montajes bind:

   /dev/sdc9 on /data/homedvl type reiserfs (rw,relatime,lazytime,user_xattr,acl)
   /dev/sdc9 on /usr/share/flightgear type reiserfs (rw,relatime,lazytime,user_xattr,acl)
   /dev/sdc9 on /var/spool/news type reiserfs (rw,relatime,lazytime,user_xattr,acl)
   /dev/sdc9 on /home/cer/terrasync type reiserfs (rw,relatime,lazytime,user_xattr,acl)
   /dev/sdc9 on /usr/src type reiserfs (rw,relatime,lazytime,user_xattr,acl)


El directorio que está activo es "/var/spool/news". Uso leafnode
nntp proxy server. Contiene 1.2 millón de ficheros en mas o menos 3 GB de
espacio usado.

El siguiente descubrimiento es que si hago:

time sync
time sync && systemctl hibernate

el sync puede tardar lo suyo, pero la hibernación es casi instantánea y no
da problemas.

A partir de ahí descubrí que no es que la hibernación se quede trabada, es
que el kernel intenta sincronizar los sistemas de ficheros, y no puede
porque uno de ellos está constantemente escribiendo, y no consigue
sincronizar hasta que el proceso termine, lo que puede tardar veinte
minutos.


El proceso en cuestión es "texpire", que es disparado por el cron. Es un
proceso que básicamente recorre todos los mensajes de las news uno a uno
(que son 1.2E6 ficheros) para ver cual es muy antiguo y borrarlo.

Hay otra cosa muy rara, que es que cuando ejecuto "sync" fuera de esa
franja de tiempo, tarda como un minuto en sincronizar. Un minuto de
actividad de escritura en esa partición. Mi sospecha es que se trata de
escribir las marcas de tiempo de los ficheros de mensajes leídos, que se
hacen con retraso debido a "relatime,lazytime" (que son los parámetros por
defecto).

Los viejos del lugar igual recuerdan que los servidores de noticias son
uno de los pocos programas que usan las marcas de tiempo que registran la
apertura de ficheros para leer.

¿Qué os parece?