¿Hay alguna otra razón para "no queda espacio en el dispositivo"?

Estoy usando Dirvish en un sistema de servidor Ubuntu para hacer una copia de seguridad de un disco duro en una unidad externa usb 3.0. Hasta hace unos días, todo funcionaba bien, pero ahora cada copia de seguridad falla con "no queda espacio en el dispositivo (28)" y "sistema de archivos lleno". Lamentablemente, no es tan simple: hay> 500 GB libres en el dispositivo.

Detalles:

rsync_error:

rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename1>.eDJiD9": No space left on device (28)
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename2>.RHuUAJ": No space left on device (28)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename3>.9tVK8Z": No space left on device (28)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename4>.t3ARSV": No space left on device (28)
[... some more files ...]
rsync: connection unexpectedly closed (2712185 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]

el registro se ve más o menos como de costumbre hasta que llega:

<SomeFilename1>
<SomeFilename2>
<SomeFilename3>
<SomeFilename4>
<PartOfAFilename>filesystem full
write error, filesystem probably full
broken pipe
RESULTS: warnings = 0, errors = 1

Pero, como se dijo anteriormente, hay mucho espacio en el dispositivo:

df -h
/dev/sdg1       2.7T  2.0T  623G  77% /mnt/backupsys/shd

y también quedan muchos inodes:

df -i
/dev/sdg1      183148544 2810146 180338398    2% /mnt/backupsys/shd

El dispositivo está montado como rw:

mount
/dev/sdg1 on /mnt/backupsys/shd type ext3 (rw)

El proceso se ejecuta como root.

Estaba a punto de decir que no he cambiado nada, pero eso no es del todo cierto: he activado acl para la unidad que estoy respaldando:

/dev/md0 on /mnt/md0 type ext4 (rw,acl)

¿Podría ser el problema? Si es así, ¿cómo? root aún tiene acceso completo a los archivos.

EDITAR:

Acabo de comprobar los directorios temporales:

• / tmp contiene solo una carpeta .webmin que está vacía
• / var / tmp está vacío

El sistema de archivos donde residen estos directorios tiene mucho espacio libre e inodos:

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       289G   55G  220G  20% /

df -i
Filesystem        Inodes   IUsed     IFree IUse% Mounted on
/dev/sda1       19202048  167644  19034404    1% /

EDIT2:

Los directorios son bastante grandes, pero no> 2 GB. El que falla la copia de seguridad ni siquiera es uno de los más grandes, contiene 7530 archivos.

EDITAR3:

Una información que no consideré relevante al publicar esta pregunta:

El día antes de que las copias de seguridad comenzaran a fallar, activé acls en los sistemas de archivos de los que se realizó una copia de seguridad. Supongo ahora que esto provocó que Dirvish (o rsync) pensara que todos los archivos habían cambiado, por lo que la lista de archivos que se iban a copiar en lugar de vincularse era muy grande. Esto podría significar que algunos tampones eran demasiado pequeños.

Hoy una copia de seguridad completa en un disco vacío funcionó a la perfección. Probaré una copia de seguridad incremental a continuación. Esto mostrará si la activación de acls fue la causa del problema.

Mi sospecha (ver EDIT3) aparentemente estaba en lo cierto: agregar soporte de acl al sistema de archivos hizo que rsync / dirvish pensara que todos los archivos habían cambiado. Entonces, en lugar de hacer una copia de seguridad incremental y simplemente crear enlaces duros a los archivos ya existentes, trató de crear una copia de seguridad completa que, por supuesto, falló porque el disco duro no tenía suficiente espacio para eso.

Entonces el mensaje de error era realmente correcto.

Después de comenzar nuevamente con un disco de copia de seguridad vacío, las copias de seguridad incrementales funcionaron como antes.

Mirar el 2% de los inodos restantes me hizo pensar en las reservas de raíz que impone el sistema de archivos EXT. Es posible que desee ver estos:

1. " Espacio reservado para root en un sistema de archivos, ¿por qué? "
2. "¿ Tamaño razonable para" bloques reservados del sistema de archivos "para discos que no son del sistema operativo? "

Intentaría .tar.gz algunas de las copias de seguridad más antiguas con la esperanza de que reduciría la cantidad de inodos en uso.

Veo que dummzeuch encuentra una solución a su problema, pero en realidad hay un caso más que encontré donde el disco puede tener suficientes inodes / espacio libre y aún muestra "no queda espacio en el dispositivo" al intentar transferir ciertos directorios.

Esto es causado por colisiones hash en dispositivos de bloque formateados con el sistema de archivos ext4 donde la indexación de directorios también está habilitada, especialmente cuando un directorio único contiene más de 100k archivos y el nombre de los archivos se genera a partir del mismo algoritmo (archivos de caché, nombres de archivo md5sum, etc. .)

La solución es probar con otro algoritmo de indexación de directorio:

tune2fs -E "hash_alg=tea" /dev/blockdev_name

o deshabilitar completamente la indexación de directorios para ese dispositivo de bloque (puede afectar el rendimiento)

tune2fs -O ^dir_index /dev/blockdev_name

Otra solución es ver qué está llenando el directorio con dichos archivos y arreglar el software.

La posible solución es dividir el contenido de la carpeta con un gran volumen de archivos en múltiples subcarpetas separadas.

Axel Wagner presenta la descripción completa del problema aquí

http://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html

Salud.

Hay un límite de tamaño de 2 GB en el directorio en sí, es decir, si tiene tantos archivos que el tamaño del directorio es> 2 GB (NO el tamaño de los archivos en el directorio), tendrá un problema. Dicho esto, con solo 2.8M inodos utilizados, eso no debería ser un problema. Suele ocurrir alrededor de 15 millones de inodes.

Entonces, esto puede no ser de mucha ayuda, pero ¿prueba ext4 en su dispositivo de respaldo?

Aumente su límite de observadores de Inotify en sysctl:

fs.inotify.max_user_watches = 100000 

Y reiniciar, o hacer la sysctl -wversión de eso también.

Eso generalmente lo hará. Algo tiene demasiados archivos abiertos en el núcleo, y el error es totalmente engañoso. Dropbox es un ejemplo clásico de esto.

Te sugiero que verifiques un par de otras cosas:

1. Mira si tu directorio temporal no se está llenando. A veces se usa para almacenamiento intermedio y se llena fácilmente.
2. Compruebe si hay un proceso que todavía contiene un descriptor para un archivo eliminado. Las posibilidades son menos probables ya que df informa el tamaño adecuado, pero aún así no dolerá.

Acabo de encontrar este tema mientras buscaba una solución a mi problema.

De hecho, hay al menos otra razón para ENOSPC. Y también lo confundo con rsync, mientras copio de un sistema de archivos ZFS a uno EXT4:

rsync: rsync_xal_set: lsetxattr(""/my/file/path"","example.xattr.attribute") failed: No space left on device (28)

En este caso:

   ENOSPC - There is insufficient space remaining to store the extended attribute.

man 7 xattr explica:

   In the current ext2, ext3, and ext4 filesystem implementations, the total bytes used by the names and values of all of a file's extended attributes
   must fit in a single filesystem block (1024, 2048 or 4096 bytes, depending on the block size specified when the filesystem was created).

En mi caso, significa que tengo que formatear todo el sistema de archivos. :-(