J'ai récemment manqué d'espace disque sur un lecteur sur un serveur FreeBSD. J'ai tronqué le fichier qui causait des problèmes mais je ne vois pas la modification reflétée lors de l'exécution df. Lorsque je cours du -d0 sur la partition, il affiche la valeur correcte. Y a-t-il un moyen de forcer la mise à jour de cette information? Qu'est-ce qui fait que la sortie ici est différente?Get `df` pour afficher les informations mises à jour sur FreeBSD
Ceci se centre probablement sur comment vous avez tronqué le fichier. du et df signaler différentes choses comme this post on unix.com explains. Juste parce que l'espace n'est pas utilisé ne veut pas nécessairement dire que c'est gratuit ...
Est-ce que df --sync fonctionne?
En BSD une entrée de répertoire est simplement l'une des nombreuses références aux données de fichier sous-jacentes (appelées inode). Lorsqu'un fichier est supprimé avec la commande rm (1), seul le nombre de références est diminué. Si le compte de référence est toujours positif (par exemple, le fichier contient d'autres entrées de répertoire en raison de liens symboliques), les données de fichier sous-jacentes ne sont pas supprimées.
Les utilisateurs BSD les plus récents ne réalisent souvent pas qu'un programme qui a un fichier ouvert contient également une référence. Cela empêche les données de fichier sous-jacentes de disparaître pendant que le processus l'utilise. Lorsque le processus ferme le fichier si le nombre de références tombe à zéro, l'espace fichier est marqué comme disponible. Ce schéma est utilisé pour éviter les problèmes de type Microsoft Windows où il ne vous laissera pas supprimer un fichier car un programme non spécifié l'a toujours ouvert.
Un moyen facile d'observer ceci est de faire ce qui suit
cp /bin/cat /tmp/cat-test
/tmp/cat-test &
rm /tmp/cat-test
Tant que le processus d'arrière-plan est mis fin à l'espace de fichier utilisé par/tmp/cat-test restent alloués et indisponibles tel que rapporté par df (1) mais la commande du (1) ne pourra pas en tenir compte car elle n'a plus de nom de fichier. Notez que si le système doit tomber en panne sans que le processus ne ferme le fichier, alors les données du fichier seront toujours présentes mais non référencées, une exécution de fsck (8) sera nécessaire pour récupérer l'espace du système de fichiers.
Les processus contenant des fichiers ouverts sont une des raisons pour lesquelles la commande newsyslog (8) envoie des signaux à syslogd ou à d'autres programmes de journalisation pour les informer qu'ils doivent fermer et rouvrir leurs fichiers journaux après les avoir tournés. Les mises à jour logicielles peuvent également affecter l'espace libre du système de fichiers car la récupération de l'espace inodé peut être différée; La commande sync (8) peut être utilisée pour encourager cela à se produire plus tôt.