Existe algum outro motivo para “não restar espaço no dispositivo”?

Question

Estou usando o Dirvish em um sistema de servidor Ubuntu para fazer o backup de um hd em uma unidade usb 3.0 externa. Até alguns dias atrás, tudo funcionava bem, mas agora cada backup falha com "nenhum espaço deixado no dispositivo (28)" e "sistema de arquivos cheio". Infelizmente não é assim tão simples: há > 500 GB livres 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 quase normal 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 é montado como rw:

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

O processo está sendo executado como root.

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

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

Poderia ser esse o problema? Se sim, como? 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 tem 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 é sequer um dos maiores, ele contém 7530 arquivos.

EDIT3:

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

Um dia antes de os backups começarem a falhar, eu havia ativado os acls nos sistemas de arquivos dos quais foi feito backup. Suponho agora que isso acionou o Dirvish (ou rsync) para pensar que todos os arquivos foram alterados, de modo que a lista de arquivos a serem copiados, em vez de vinculados, 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 em seguida. Isso mostrará se a ativação de acls foi a causa do problema.

    

Answer 1

Minha suspeita (veja EDIT3) aparentemente estava certa: Adicionando suporte a acl ao sistema de arquivos, o rsync / dirvish achou que todos os arquivos haviam mudado. Então, em vez de fazer um backup incremental e apenas criar hard links 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 correta.

Depois de começar de novo com um disco de backup vazio, os backups incrementais funcionaram como antes.

    

Answer 2

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

1. " Espaço reservado para raiz 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 SO? "

Eu tentaria .tar.gz alguns dos backups mais antigos, esperando que isso reduzisse o número de inodes em uso.

    

Answer 3

Eu vejo aquele dummzeuch encontrar uma solução para seu problema, mas na verdade existe mais um caso que achei onde o disco pode ter inodes / espaço livre suficiente e ainda mostrar "nenhum espaço deixado no dispositivo" durante a tentativa de transferir certos diretórios. / p>

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

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

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

ou para desabilitar completamente a indexação de diretório para esse dispositivo de bloco (pode afetar 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.

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

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

link

Felicidades.

    

Answer 4

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

Portanto, isso pode não ajudar muito, mas tente o ext4 no seu dispositivo de backup?

    

Answer 5

Aumente o limite de observadores do Inotify em sysctl:

fs.inotify.max_user_watches=100000 

E reinicie ou use a versão sysctl -w disso também.

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

    

Answer 6

Eu sugiro que você verifique algumas outras coisas:

1. Verifique 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 existe um processo que ainda mantém um descritor em um arquivo excluído. As chances são menos prováveis, já que o df relata tamanho adequado, mas ainda assim não vai doer.

Answer 7

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

De fato, há pelo menos outro motivo para o ENOSPC. E também o rsync, ao copiar 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)

Neste 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 eu preciso reformatar todo o sistema de arquivos. : - (