14 votos

¿Hay alguna otra razón por la que "no queda espacio en el dispositivo"?

Estoy usando Dirvish en un servidor Ubuntu sistema para realizar copias de seguridad de un hd externo usb 3.0 unidad de disco. 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 archivo completo". Lamentablemente no es tan simple: Hay > 500 GB de espacio libre 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 bastante mucho como de costumbre hasta que llega a:

<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 un montón de espacio en el dispositivo:

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

y también hay un montón de inodos de la izquierda:

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 que no es del todo cierto: Me he cambiado de acl para la unidad yo soy la copia de seguridad:

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

Que podría ser el problema? Si sí, ¿cómo? root todavía tiene acceso completo a los archivos.

EDITAR:

Acabo de comprobar los directorios temporales:

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

el sistema de archivos donde estos directorios residir tiene un montón de espacio libre y los 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 más de 2 GB. Aquella en la que la copia de seguridad falla no es ni siquiera uno de los más grandes, que contiene 7530 archivos.

EDIT3:

Una información que yo no considero relevante cuando se publique esta pregunta:

El día antes de las copias de seguridad comenzó a fallar me había activado acl en los sistemas de archivo que se copia de seguridad. Supongo que ahora que este activa Dirvish (o rsync) a pensar en todos los archivos que se había cambiado por lo que la lista de archivos que se copian en lugar de duro vinculados era muy grande. Esto podría significar que algunos búferes eran demasiado pequeñas.

Hoy en día una completa copia de seguridad a un disco vacío funcionó a la perfección. Voy a intentar una copia de seguridad incremental siguiente. Esto mostrará si la activación de acl fue la causa del problema.

4voto

Vlad GURDIGA Puntos 141

Mirando el 2% de los inodos de la izquierda me hizo pensar acerca de la root de la reserva de que el sistema de archivos EXT impone. Es posible que desee comprobar estos:

  1. "El espacio reservado para el usuario root en un sistema de ficheros - ¿por qué?"
  2. "Tamaño razonable para el "sistema de archivos reservados bloques" para que no OS discos?"

Yo intentaría .tar.gz algunas de las copias de seguridad antiguas con la esperanza de reducir el número de inodos en uso.

4voto

dummzeuch Puntos 273

Mi sospecha (ver EDIT3) al parecer estaba en lo cierto: la Adición de soporte de acl para el sistema de archivos hizo rsync/dirvish pensar que todos los archivos que había cambiado. Así que en lugar de hacer una copia de seguridad incremental y acaba de crear enlaces duros a los ficheros ya existentes, se trató de crear una copia de seguridad completa que por supuesto fracasó porque el disco duro no tiene espacio suficiente para que.

Así que el mensaje de error era de hecho correcta.

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

1voto

Rafiq Maniar Puntos 835

Hay un límite de 2GB de tamaño en el directorio de sí mismo - es decir, si usted tiene muchos archivos que el tamaño de directorio >2GB (NO el tamaño de los archivos EN el directorio), vas a tener un problema. Habiendo dicho que, con tan sólo un 2,8 M de los inodos de usa, que no debería ser un problema. Generalmente ocurre alrededor de 15 millones de inodes.

Así que esto no puede ser de mucha ayuda - pero trate de ext4 en el dispositivo de copia de seguridad?

1voto

Sirex Puntos 4053

Aumentar su Inotify observadores límite en sysctl:

fs.inotify.max_user_watches=100000 

Y reiniciar el equipo, o hacer la sysctl -w versión de que también.

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

0voto

Aditya Patawari Puntos 805

Yo sugeriría usted para comprobar un par de cosas:

  1. Mira si tu directorio temporal no está llena. A veces se la utiliza para el almacenamiento intermedio y se llena fácilmente.
  2. Compruebe si hay un proceso que aún se mantiene un descriptor de un archivo eliminado. Las posibilidades son menos probable, ya que df informes de tamaño adecuado, pero todavía no duele.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: