Inodos no referencedos en la instancia de EC2 linux

Tengo una instancia de Amazon EC2 que estoy usando como server de files NFS. Está utilizando una matriz RAID0 de 5x1TB de volumen. El sistema es muy intensivo en E / S y los files se están escribiendo / copyndo / eliminando a través de NFS todo el time. A menudo, noto que hay una GRAN discrepancia entre el espacio de disco utilizado y el espacio libre disponible. (Estoy comprobando mientras el sistema está inactivo y no se están escribiendo files en el compartimiento de files / sistema). Mi única "Solución" para esto es apagar la instancia y reiniciarla (el reinicio no funciona y simplemente cuelga la máquina). Cuando se reinicia, ejecuta fsck y puedo ver en el logging del sistema (muchos) Inodes "sin reference" que se están limpiando (este no es el logging completo):

  25.110924] EXT4-fs (dm-1): ext4_orphan_cleanup: deleting unreferenced inode 122291727 [ 25.114687] EXT4-fs (dm-1): ext4_orphan_cleanup: deleting unreferenced inode 122291723 [ 25.118610] EXT4-fs (dm-1): ext4_orphan_cleanup: deleting unreferenced inode 122291703 [ 25.135184] EXT4-fs (dm-1): ext4_orphan_cleanup: deleting unreferenced inode 122291722 [ 25.140005] EXT4-fs (dm-1): ext4_orphan_cleanup: deleting unreferenced inode 122291725 [ 25.144013] EXT4-fs (dm-1): ext4_orphan_cleanup: deleting unreferenced inode 122291705 [ 25.148008] EXT4-fs (dm-1): 735 orphan inodes deleted [ 25.150286] EXT4-fs (dm-1): recovery complete [ 26.126887] EXT4-fs (dm-1): mounted filesystem with ordenetworking data mode. Opts: (null) [ OK ] 

No puedo encontrar ninguna solución para esto en línea. ¿Alguien sabe qué está causando esto o cómo prevenirlo? ¿O tal vez arreglarlo sin desmontar el disco?

Algo más de información:

Información de versión:

 Linux version 3.10.42-52.145.amzn1.x86_64 (mockbuild@gobi-build-64003) (gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC) ) #1 SMP Tue Jun 10 23:46:43 UTC 2014 

RAID0 array mount en /etc/fstab siguiente manera:

 /dev/vg0/data /data ext4 defaults,auto,noatime,noexec 0 0 

/etc/mdadm.conf:

 DEVICE /dev/xvdk /dev/xvdj /dev/xvdi /dev/xvdh /dev/xvdg ARRAY /dev/md0 metadata=1.2 name=ip-172-31-10-215:0 UUID=4c4fb472:e0540788:69a83d01:a75a8a3e 

/ etc / exports:

 /data *(rw,sync) 

Los clientes montan el recurso compartido NFS de la siguiente manera:

 xxxx:/data /mnt/fileserver nfs defaults 0 0 

El comportamiento que describes puede deberse a aplicaciones que mantienen abiertos los files incluso después de que se hayan eliminado. Si una aplicación tiene un file abierto (por ejemplo, tail ), y aparece otra aplicación que elimina el file (por ejemplo, rm ), la primera aplicación continuará manteniendo una reference del file hasta que la primera aplicación cierre el file. En ese punto, el sistema de files reconocerá que el file se borró y no se abre y borrará las references.

Aquí hay una explicación demasiado simplist de cómo se relacionan los files y los inodos. Un file es esencialmente un logging en un sistema de files que asigna un nombre (o nombres) a un inodo específico. Los files abiertos son referencedos por inodo. Cuando elimina un file, en realidad está eliminando el enlace entre el nombre y el inodo, pero un file abierto también mantiene un enlace entre el descriptor de file abierto y el inodo también. Al cerrar el file, se elimina el enlace entre el descriptor de file abierto y el inodo. El inodo no será reclamado por el sistema de files hasta que todos los enlaces hayan sido eliminados.

Cuando miras el espacio libre reportado por el sistema de files, te dice el espacio asociado con todos los inodos actualmente marcados como usados. Cuando mira a través de todos los directorys y resume el espacio de files utilizado por cada file / directory, puede ser menor si los files se han eliminado pero todavía están abiertos. El escaneo de su directory no verá el espacio utilizado por los files a los que se les quitaron sus enlaces de nombre.

Cuando apaga el sistema, no da la oportunidad a las aplicaciones de cerrar sus files. Sin esa posibilidad, el sistema de files no tiene la oportunidad de reclamar los inodos utilizados por los descriptores de files abiertos de los files eliminados. Cuando el sistema arranca, el sistema de files ve estos inodos sin que nada los señale. Estos se llaman "inodes huérfanos" y el sistema de files le permite saber que está borrando la reference del file.

Una herramienta que puede usar para search processs con descriptores de files abiertos es lsof . Si ejecuta esto en un process, mostrará todos los descriptores de file abiertos de ese process. Los files eliminados generalmente aparecerán como (deleted) , dependiendo de la versión.

    Intereting Posts