Y a-t-il une autre raison pour «qu'il n'y ait plus d'espace sur l'appareil»?

J'utilise Dirvish sur un système de serveur Ubuntu pour sauvegarder un disque dur sur un disque USB 3.0 externe. Jusqu'à il y a quelques jours, tout fonctionnait bien, mais maintenant chaque sauvegarde échoue avec "plus d'espace sur l'appareil (28)" et "système de fichiers plein". Malheureusement, ce n'est pas si simple: il y a> 500 Go d'espace libre sur l'appareil.

Détails:

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]

le journal ressemble à peu près comme d'habitude jusqu'à ce qu'il frappe:

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

Mais, comme indiqué ci-dessus, il y a beaucoup d'espace sur l'appareil:

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

et il y a aussi beaucoup d'inodes:

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

L'appareil est monté en rw:

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

Le processus s'exécute en tant que root.

J'allais dire que je n'ai rien changé mais ce n'est pas tout à fait vrai: j'ai allumé acl pour le lecteur que je sauvegarde:

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

Est-ce que cela pourrait être le problème? Si oui, comment? root a toujours un accès complet aux fichiers.

ÉDITER:

Je viens de vérifier les répertoires temporaires:

• / tmp contient uniquement un dossier .webmin qui est vide
• / var / tmp est vide

le système de fichiers où ces répertoires résident a beaucoup d'espace libre et d'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:

Les répertoires sont assez volumineux, mais pas> 2 Go. Celui où la sauvegarde échoue n'est même pas l'un des plus importants, il contient 7530 fichiers.

EDIT3:

Une information que je n'ai pas jugée pertinente lors de la publication de cette question:

La veille de l'échec des sauvegardes, j'avais activé acls sur les systèmes de fichiers sauvegardés. Je suppose maintenant que cela a déclenché Dirvish (ou rsync) pour penser que tous les fichiers avaient changé, de sorte que la liste des fichiers qui devaient être copiés plutôt que liés en dur était très grande. Cela pourrait éventuellement signifier que certains tampons étaient trop petits.

Aujourd'hui, une sauvegarde complète sur un disque vide fonctionnait parfaitement. J'essaierai ensuite une sauvegarde incrémentielle. Cela montrera si l'activation des acls était la cause du problème.

Mon soupçon (voir EDIT3) était apparemment exact: l'ajout du support acl au système de fichiers a fait penser à rsync / dirvish que tous les fichiers avaient changé. Ainsi, au lieu de faire une sauvegarde incrémentielle et de simplement créer des liens durs vers les fichiers déjà existants, il a essayé de créer une sauvegarde complète qui a bien sûr échoué car le disque dur n'avait pas assez d'espace pour cela.

Le message d'erreur était donc en fait correct.

Après avoir redémarré avec un disque de sauvegarde vide, les sauvegardes incrémentielles ont fonctionné comme auparavant.

Regarder les 2% d'inodes restants m'a fait penser aux réserves root imposées par le système de fichiers EXT. Vous voudrez peut-être les vérifier:

1. " Espace réservé pour root sur un système de fichiers - pourquoi? "
2. " Taille raisonnable pour les" blocs réservés au système de fichiers "pour les disques non-OS? "

J'essaierais de .tar.gz certaines des sauvegardes plus anciennes en espérant que cela réduirait le nombre d'inodes en cours d'utilisation.

Je vois que dummzeuch trouve une solution à son problème mais il y a en fait un cas de plus où j'ai trouvé où le disque peut avoir suffisamment d'inodes / d'espace libre et montrant toujours "plus d'espace sur le périphérique" lors de la tentative de transfert de certains répertoires.

Cela est dû à des collisions de hachage sur des périphériques de bloc formatés avec le système de fichiers ext4 où l'indexation de répertoire est également activée, en particulier lorsque le répertoire unique contient plus de 100 000 fichiers et que le nom des fichiers est généré à partir du même algorithme (fichiers de cache, noms de fichiers md5sum, etc. .)

La solution consiste à essayer avec un autre algorithme d'indexation de répertoire:

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

ou pour désactiver complètement l'indexation de répertoire pour ce périphérique de blocage (peut nuire aux performances)

tune2fs -O ^dir_index /dev/blockdev_name

Une autre solution consiste à voir ce qui remplit le répertoire avec ces fichiers et à réparer le logiciel.

La solution possible est de diviser le contenu du dossier avec un énorme volume de fichiers en plusieurs sous-dossiers séparés.

La description complète du problème est présentée par Axel Wagner ici

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

À votre santé.

Il y a une limite de taille de 2 Go sur le répertoire lui-même - c'est-à-dire si vous avez tellement de fichiers que la taille du répertoire est> 2 Go (PAS la taille des fichiers DANS le répertoire), vous aurez un problème. Cela dit, avec seulement 2,8 millions d'inodes utilisés, cela ne devrait pas être un problème. Se produit généralement autour de 15 millions d'inodes.

Donc, cela peut ne pas être très utile - mais essayez ext4 sur votre périphérique de sauvegarde?

Augmentez votre limite d'observateurs Inotify dans sysctl:

fs.inotify.max_user_watches = 100000 

Et redémarrez, ou faites la sysctl -wversion de cela aussi.

Cela suffit généralement. Quelque chose a trop de fichiers ouverts dans le noyau et l'erreur est totalement trompeuse. Dropbox en est un exemple classique.

Je vous suggère de vérifier quelques autres choses:

1. Regardez si votre répertoire temporaire ne se remplit pas. Parfois, il est utilisé pour le stockage intermédiaire et il se remplit facilement.
2. Vérifiez s'il existe un processus qui contient toujours un descripteur pour un fichier supprimé. Les chances sont moins probables puisque df rapporte une taille correcte mais cela ne fera pas de mal.

Je viens de trouver ce sujet en recherchant une solution à mon problème.

En effet, il y a au moins une autre raison pour ENOSPC. Et je le foud également avec rsync, tout en copiant d'un système de fichiers ZFS vers un EXT4:

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

Dans ce cas:

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

man 7 xattr explique:

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

Dans mon cas, cela signifie que je dois reformater l'ensemble du système de fichiers. :-(