Existe algum outro motivo para "não resta espaço no dispositivo"?

Estou usando o Dirvish em um sistema de servidor Ubuntu para fazer backup de um hd em uma unidade USB 3.0 externa. Até alguns dias atrás, tudo funcionava bem, mas agora todo backup falha com "nenhum espaço restante no dispositivo (28)" e "sistema de arquivos cheio". Infelizmente, não é assim tão simples: existem> 500 GB gratuitos no dispositivo.

Detalhes:

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]

o log parece mais ou menos o habitual até atingir:

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

Mas, como dito acima, há muito espaço no dispositivo:

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

e também há muitos inodes restantes:

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

O dispositivo está montado como rw:

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

O processo está sendo executado como raiz.

Eu estava prestes a dizer que não mudei nada, mas isso não é verdade: ativei o acl para a unidade que estou fazendo backup:

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

Esse poderia ser o problema? Se sim, como? o root ainda tem acesso total aos arquivos.

EDITAR:

Acabei de verificar os diretórios temporários:

• / tmp contém apenas uma pasta .webmin que está vazia
• / var / tmp está vazio

o sistema de arquivos em que esses diretórios residem possui bastante espaço livre e inodes:

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:

Os diretórios são bastante grandes, mas não> 2 GB. Aquele em que o backup falha não é nem um dos maiores, contém 7530 arquivos.

EDIT3:

Uma informação que não considerei relevante ao postar esta pergunta:

Um dia antes dos backups começarem a falhar, eu havia ativado o acls nos sistemas de arquivos dos quais foi feito backup. Suponho agora que isso tenha acionado o Dirvish (ou rsync) para pensar que todos os arquivos haviam sido alterados, de modo que a lista de arquivos que deveriam ser copiados em vez de com links físicos era muito grande. Isso poderia significar que alguns buffers eram muito pequenos.

Hoje, um backup completo para um disco vazio funcionou perfeitamente. Vou tentar um backup incremental a seguir. Isso mostrará se a ativação de acls foi a causa do problema.

Minha suspeita (veja EDIT3) aparentemente estava certa: A adição de suporte a ACL ao sistema de arquivos fez o rsync / dirvish pensar que todos os arquivos haviam sido alterados. Portanto, em vez de fazer um backup incremental e apenas criar links físicos para os arquivos já existentes, ele tentou criar um backup completo que, obviamente, falhou porque o disco rígido não tinha espaço suficiente para isso.

Portanto, a mensagem de erro estava realmente correta.

Após iniciar novamente com um disco de backup vazio, os backups incrementais funcionaram como antes.

Observar os 2% de inodes restantes me fez pensar nas reservas raiz que o sistema de arquivos EXT impõe. Você pode querer verificar isso:

1. " Espaço reservado para root em um sistema de arquivos - por quê? "
2. " Tamanho razoável para" blocos reservados do sistema de arquivos "para discos que não são do sistema operacional? "

Eu tentaria .tar.gz alguns dos backups mais antigos, com a esperança de reduzir o número de inodes em uso.

Vejo que o dummzeuch encontra uma solução para o problema dele, mas na verdade há mais um caso em que o disco pode ter inodes / espaço livre suficientes e ainda mostrando "não resta espaço no dispositivo" ao tentar transferir determinados diretórios.

Isso é causado por colisões de hash em dispositivos de bloco formatados com o sistema de arquivos ext4, onde a indexação de diretório também é ativada, especialmente onde um único diretório hospeda mais de 100k arquivos e o nome dos arquivos é gerado a partir do mesmo algoritmo (arquivos de cache, nomes de arquivos md5sum etc.) .)

A solução é tentar com outro algoritmo de indexação de diretório:

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

ou desativar completamente a indexação de diretório para esse dispositivo de bloco (pode prejudicar o desempenho)

tune2fs -O ^dir_index /dev/blockdev_name

Outra solução é ver o que está preenchendo o diretório com esses arquivos e corrigir o software.

A solução possível é dividir o conteúdo da pasta com um enorme volume de arquivos para várias subpastas separadas.

A descrição completa do problema é apresentada por Axel Wagner aqui

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

Felicidades.

Há um limite de tamanho de 2 GB no próprio diretório - ou seja, se você tiver tantos arquivos que o tamanho do diretório seja> 2 GB (NÃO o tamanho dos arquivos do diretório), você terá um problema. Dito isto, com apenas 2,8 milhões de inodes usados, isso não deve ser um problema. Geralmente acontece em torno de 15 milhões de inodes.

Portanto, isso pode não ser de muita ajuda - mas tente o ext4 no seu dispositivo de backup?

Aumente seu limite de observadores do Inotify em sysctl:

fs.inotify.max_user_watches = 100000 

E reinicie, ou faça a sysctl -wversão disso também.

Isso geralmente faz isso. Algo tem muitos arquivos abertos no kernel, e o erro é totalmente enganador. O Dropbox é um exemplo clássico disso.

Eu sugiro que você verifique algumas outras coisas:

1. Veja se o seu diretório temporário não está ficando cheio. Às vezes, é usado para armazenamento intermediário e fica cheio facilmente.
2. Verifique se há um processo que ainda esteja mantendo um descritor para um arquivo excluído. As chances são menos prováveis, já que o df informa o tamanho adequado, mas ainda assim não vai doer.

Acabei de encontrar este tópico enquanto procurava uma solução para o meu problema.

De fato, há pelo menos por outro motivo para o ENOSPC. Também uso o rsync, enquanto copia de um sistema de arquivos ZFS para um EXT4:

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

Nesse 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).

No meu caso, isso significa que tenho que reformatar todo o sistema de arquivos. :-(