J'ai un serveur de fichiers où df rapporte 94% de/full. Mais selon du, beaucoup moins est utilisé:
# df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 270G 240G 17G 94% /
# du -hxs /
124G /
J'ai lu que les fichiers ouverts mais supprimés pouvaient en être responsables mais un redémarrage n'a pas résolu ce problème.
C'est Linux, ext3.
cordialement
Ok, je l'ai trouvé.
J'avais une ancienne sauvegarde sur/mnt/Backup dans le même système de fichiers puis un lecteur externe monté à cet endroit. Donc, du n'a pas vu les fichiers. Donc, le nettoyage m'a redonné de l'espace disque.
C'est probablement arrivé de cette façon: le disque externe a été démonté une fois pendant l'exécution du script de sauvegarde quotidienne.
Je ne pense pas que vous trouverez une explication plus approfondie que ce lien pour toutes les raisons pour lesquelles il pourrait être désactivé. Quelques faits saillants qui pourraient aider:
Quelle est votre utilisation d'inode, si elle est presque à 100% qui peut gâcher les choses:
df -i
Quelle est votre taille de bloc? Beaucoup de petits fichiers et une grande taille de bloc pourraient l'incliner un peu.
Sudo tune2fs -l/dev/sda1 | grep 'Taille du bloc'
Fichiers supprimés, vous avez dit que vous avez enquêté sur cela, mais pour obtenir l'espace total, vous pouvez utiliser le pipeline suivant (j'aime trouver au lieu de lsof juste parce que lsof est une douleur à analyser):
Sudo find/proc/*/fd -printf "% l\t% s\n" | grep supprimé | coupe -f2 | (tr '\ n' +; écho 0) | avant JC
Cependant, c'est presque 2x hors tension. Exécutez fsck sur la partition lorsqu'elle est démontée pour être sûre.
Cela ressemble à un cas de suppression de fichiers alors que les processus les ont toujours ouverts. Cette déconnexion se produit car la commande du totalise l'espace des fichiers qui existent dans le système de fichiers, tandis que df affiche les blocs disponibles dans le système de fichiers. Les blocs d'un fichier ouvert et supprimé ne sont pas libérés tant que ce fichier n'est pas fermé.
Vous pouvez trouver quels processus ont des fichiers ouverts mais supprimés en examinant/proc
find /proc/*/fd -ls | grep deleted
La raison la plus probable dans votre cas est que vous avez beaucoup de fichiers très petits (plus petits que la taille de votre bloc sur le lecteur). Dans ce cas, df indiquera la somme de tous les blocs utilisés, tandis que du signalera la somme réelle des tailles de fichier.
Je suis d'accord que
lsof +L 1 /home | grep -i deleted
est un bon point de départ, dans mon cas, je remarque que j'avais beaucoup de scripts Perl en cours d'exécution et que je gardais beaucoup de fichiers en vie, même s'ils étaient censés être supprimés.
J'ai tué les fonctions Perl, ce qui a rendu du
et df
presque identiques, le dossier est fermé.
Par défaut, lorsque vous formatez un système de fichiers avec EXT3, 5% du lecteur est réservé à root. df tient compte de cette réserve lorsqu'il signale ce qui est disponible, tandis que du montre ce qui est réellement utilisé.
Vous pouvez afficher les blocs réservés en exécutant:
tune2fs -l/dev/sda | grep -i reserve
et vous obtiendrez quelque chose comme:
Reserved block count: 412825
Reserved GDT blocks: 1022
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
Si vous souhaitez ajuster cela à un pourcentage inférieur, vous pouvez le faire avec quelque chose comme
tune2fs -m 1/dev/sda
Vous pouvez le réduire à 0, mais comme il s'agit de votre système de fichiers racine, je me méfierais de le faire. Si le système de fichiers est réellement rempli, il peut être difficile d'effectuer des tâches de maintenance pour le nettoyer.
Est-il possible que du n'ajoute pas aussi la taille des répertoires? Pourtant, cela semble être une énorme différence, cela ne peut pas être responsable de tout cela.