Невидимый файловый отпечаток (du vs df)

Думаю, это ожидаемое поведение.

Допустим, у вас есть сервер с файловой системой, смонтированной как /foo, и эта файловая система содержит два каталога barи baz, что дает вам /foo/bar/и /foo/baz/. Скажем:

• /foo— файловая система размером 100 ГБ
• /foo/bar/содержит 10 ГБ файлов
• /foo/baz/содержит 20 ГБ файлов
• оставляя 70 ГБ свободными.

Если вы затем экспортируете /foo/barчерез NFS. И смонтировать на клиенте как /mnt/bar. Затем на клинте вы выполняете оба:

df -h /mnt/bar
du -hs /mnt/bar

Я ожидал:

• df, чтобы показать 30 ГБ занято, 70 ГБ свободно, всего 100 ГБ.
• du, чтобы показать, что используется только 10 ГБ.

Остальные 20 ГБ не были доступны через NFS, но они будут отображаться при вашем использовании при опросе в df. Это нормальное поведение для протоколов удаленной файловой системы в большинстве операционных систем.

Короче говоря, dfпоказывает статистику для всей файловой системы, смонтированной на удаленном сервере. duпоказывает общий размер файлов, к которым у вас есть доступ.

Примечание.:Существует много других причин, по которым duможет отсутствовать доступ к некоторым файлам, содержащимся в файловой системе. Несколько других причин включают:

• Можно удалить(разорвать связь)с файлом, пока программа все еще записывает в него. В этом случае файл остается на диске до тех пор, пока не будут удалены все ссылки (, включая дескрипторы открытых файлов ).duне может их найти, потому что у них нет имени файла. Но у них по-прежнему будет индексный дескриптор, и поэтому они все равно будут отображаться при проверке с помощью df.
• Точно так же иногда могут быть повреждены файловые системы. Файлы все еще могут существовать после того, как все ссылки были закрыты из-за повреждения. Это одна из веских причин для выполнения полу-регулярных fsck проверок вашего диска.

На сегодняшний день наиболее вероятным в вашем сценарии является пример экспорта, который я показал вверху. Но если вас это беспокоит, размонтируйте и fsckваш диск.