Système de fichiers Linux; différence dans le calcul de la taille en utilisant df & du

Lorsque je lance, dfcela montre que le périphérique racine est plein.

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             9.9G  9.4G     0 100% /

J'ai regardé l' inodeutilisation et il y a à peu près de l'espace disponible pour le périphérique racine

Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sda1               640K    103K    538K   16% /

Mais, lorsque j'exécute la ducommande, cela montre que je n'ai utilisé que 2Gsur 9.9G.

ip-XXX-XXX-XXX-XXX:/$ du -xh --max-depth=1
14M ./etc
4.0K ./mnt
96K ./tmp
3.5M ./bin
0   ./sys
964K ./boot
4.0K ./srv
0   ./dev
55M ./lib
25M ./root
1.1G ./usr
4.0K ./opt
846M ./var
4.3M ./sbin
23M ./home
16K ./lost+found
0   ./proc
2.0G .

Cela me rend fou et intéressant aussi. C'est un gros problème pour nous car le disque racine /est plein et une partie de la fonction de notre site échoue.

Veuillez m'aider à résoudre (comprendre également) ce problème.

Merci.

Lorsque les fichiers sont supprimés dans * nix, ils continuent de vivre sur le disque (et occupent de l'espace disque) aussi longtemps qu'un processus les a ouverts. Il est assez courant d'en profiter pour «sécuriser» les fichiers temporaires en les créant avec une petite taille, en les supprimant, puis en utilisant le fichier supprimé pour stocker les données sans avoir à se soucier des autres processus d'y accéder (facilement), donc la quantité d'espace dans les fichiers supprimés peut devenir assez importante si, par exemple, une base de données temporaire ou une session d'édition multimédia est gérée de cette manière. Une autre possibilité pour la façon dont vous pourriez avoir autant d'espace "perdu" serait si le système a été mis à niveau (plusieurs fois) sans redémarrer ou redémarrer les programmes, ce qui entraîne que toutes vos anciennes bibliothèques .so sont maintenues ouvertes par des programmes qui ont été lancés avant la mise à niveau et sont toujours en cours d'exécution.

dfvoit l'espace utilisé par ces fichiers car il regarde simplement combien d'espace est alloué sur le périphérique, mais dune les voit pas car il n'y a aucune entrée de répertoire correspondante.

L'espace utilisé "caché" comme celui-ci ne peut être libéré que lorsque les processus qui ont supprimé des fichiers ouverts les ferment. Vous pouvez trouver ces processus avec la fusercommande et les terminer (ou, pour de nombreux démons, envoyer un signal leur disant de fermer et de rouvrir tous les fichiers ouverts).

Il y a eu des moments où si le disque est plein, il peut ensuite être confondu jusqu'à redémarrer / remonter que le disque est toujours plein, même lorsque vous avez supprimé une charge de fichiers.

De mon côté, j'ai simplement redémarré syslogd pour récupérer l'espace disque. Il me manquait 3 Go! Mon serveur était opérationnel depuis 250 jours.

Il existe un moyen de nettoyer l'espace sans redémarrer l'application. Voici les détails:

1. Disons que vous avez un processus en foocours d'exécution et que vous créez un fichier de 2 Go nommé abc.log. Supposons maintenant que abc.log soit supprimé par quelqu'un d'autre.

2. Obtenez foole pid (disons 123). Ainsi /proc/123/fd, la liste des descripteurs de fichiers ouverts par foo. Un avec abc.log s'affichera comme supprimé. Disons que fdabs.log est 111. Si vous exécutez less /proc/123/fd/111, il vous montrera toujours tous ces 2 Go de données.

3. Courez echo " " > /proc/123/fd/111. Cela écrasera le contenu avec une chaîne vide. Après cette commande, si vous essayez, dfelle affichera 2 Go supplémentaires récupérés en nettoyant abc.log.

C'est ça. J'ai essayé cela sur CentOS et cela fonctionne.