У меня есть 115GBраздел на жестком диске (вывод cgdisk /dev/sdaниже):
Part. # Size Partition Type Partition Name
----------------------------------------------------------------
1007.0 KiB free space
1 499.0 MiB Windows RE Basi
2 100.0 MiB EFI System EFI
3 16.0 MiB Microsoft reserved Micr
5 43.9 GiB Linux filesystem ubuntu-root
6 43.9 GiB Linux filesystem ubuntu-home
4 114.9 GiB Linux filesystem data <--- this partition
7 29.5 GiB Linux filesystem
И я смонтировал этот раздел /dataв моем /etc/fstab:
UUID=<drive-uuid> /data ext4 defaults 0 0
Когда я это делаю df -h /data, я получаю следующий результат:
Filesystem Size Used Avail Use% Mounted on
/dev/sda4 113G 96G 11G 90% /data
И когда я использую duвот так: du /data -h --max-depth=1 | sort -hr, я вижу это:
51G /data
40G /data/virtual-box
4.4G /data/temp
4.1G /data/manjaro-minikube
1.9G /data/.nuget
764M /data/OneDrive
62M /data/manjaro-lxd
40K /data/.minikube
16K /data/lost+found
который, если я не ошибаюсь, показывает, что /dataзанимает 51Gи затем у меня есть каталоги virtual-box, temp, manjaro-minikube, и .nugetзанимающие место (остальные не занимают значительного места)
Если я сделаю длинный список моего каталога ( ls -alh /data):
total 68K
drwxr-xr-x 10 farzad farzad 4.0K Aug 13 21:47 .
drwxr-xr-x 19 root root 4.0K Jul 13 10:32 ..
drwx------ 2 farzad farzad 16K Mar 22 18:22 lost+found
drwx--x--x 15 root root 4.0K Aug 20 17:47 manjaro-lxd
drwxr-xr-x 3 farzad farzad 4.0K Jul 3 18:16 manjaro-minikube
drwxrwxr-x 9 farzad farzad 4.0K Jul 30 17:38 .minikube
drwxr-xr-x 202 farzad farzad 16K Aug 17 10:00 .nuget
drwxr-xr-x 3 farzad farzad 4.0K Aug 13 21:47 OneDrive
drwxrwxr-x 16 farzad farzad 4.0K Jun 3 21:45 temp
drwxr-xr-x 6 farzad farzad 4.0K Aug 20 20:21 virtual-box
Я не вижу никаких файлов или чего-либо, что способствовало бы этому 51G, /dataпоэтому я ожидаю, что на моем диске будет почти 65Gпустое место, но по какой-то причине /dataродительский каталог занимает 51Gвсе свое место!
Я пытался исследовать Интернет, но ничего не нашел. Может кто-нибудь, пожалуйста, дайте мне знать, что происходит?
ОБНОВЛЯТЬ
Как и предлагалось в ответах, я запустил lsof /data | grep deleted(как root), но не получил никакого результата, хотя и вижу предупреждение, которое, я не уверен, имеет отношение к делу:
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
Output information may be incomplete.
решение1
Ваш /dataзанимает 51G. Это включает все подкаталоги и файлы внутри него. Если вы добавите размеры, сообщенные duдля подкаталогов (и учтете проблемы округления), вы получите около 51G. Если бы были обычные файлы непосредственно в , они бы также /dataвнесли вклад в значение, сообщенное для ./data
Так что duне сообщает о высоком использовании. Это dfто, что сообщает о высоком использовании: 96Gиспользуется в файловой системе.
Поскольку /dataэто точка монтирования, можно ожидать, что эти два значения будут одинаковыми. Но эти два инструмента работают по-разному: duобходят каталоги и добавляют размеры обнаруженных объектов, dfзапрашивают файловую систему о ее знаниях о собственном состоянии.
Такое большое расхождение может быть вызвано следующими причинами:
duне смог добраться (или получить информацию о) всех объектах. Была ли какая-тоpermission deniedошибка?- В файловой системе есть несоответствия;
fsck.ext4этоe2fsckможет помочь. (вероятно) Есть по крайней мере один файл, который был удален (все записи каталога, указывающие на соответствующий inode, были удалены, файл не отображается ни в одном списке каталогов, поэтому
duне может знать о нем), но он все еще используется каким-то процессом (поэтому файловая система сохраняет данные и учитывает их при отправке отчетов вdf). Смотритеэтот ответ,этот вопрос.Следующая команда должна найти такие файлы и процессы, их использующие:
lsof /data | grep deletedПример вывода:
some_daemon … … … … … … … /data/temp/huge_file (deleted)Это означает, что файловая система действительно удалит
huge_fileтолько после того, какsome_daemonпрекратит ее использовать. Обратите внимание, что в целом процесс все еще может добавлять к файлу или обрезать его, поэтому файл может увеличиваться или уменьшаться. Это повлияет на то, чтоdfговорит, но не наdu.
решение2
Итак, оказалось, что здесь было несколько проблем (спасибо @Kamil за помощь в их обнаружении):
Хотя изначально я интуитивно предполагал, что сумма, выдаваемая dufor, /dataпредставляет собой сумму всех его дочерних каталогов (с некоторым округлением), полагаю, я пытался оправдать расхождения между dfи duи подумал, что мне следует суммировать duвывод for /dataи всех его дочерних каталогов, чтобы получить тот же результат, что и df.
Другая проблема, которая является основной причиной расхождений, была связана с тем, как я настроил свой /etc/fstab:
UUID=<uuid> /data ext4 defaults 0 0
^
ISSUE
Когда я создавал свой /etc/fstab, я думал, что мне не придется продлевать загрузку, включив проверки файловой системы ( fsck) на моем монтировании, отсюда 0и шестое поле, но, как оказалось, это приводило к тому, что иноды не очищались, что и приводило к БОЛЬШОЙ разнице между dfи du.
Итак, глядя на man 5 fstab, мы видим, что для включения проверок корневая файловая система должна иметь значение 1, а другие файловые системы должны иметь значение 2, поэтому я изменил строку следующим образом:
UUID=<uuid> /data ext4 defaults 0 2
И после перезапуска было сообщено о множестве проблем fsck, я решил их исправить, и вот вывод du /data -h --max-depth=1 | sort -hr:
28G /data
16G /data/virtual-box
4.5G /data/temp
4.1G /data/manjaro-minikube
1.9G /data/.nuget
824M /data/OneDrive
64M /data/manjaro-lxd
40K /data/.minikube
16K /data/lost+found
И вывод df /data -h:
Filesystem Size Used Avail Use% Mounted on
/dev/sda4 113G 28G 80G 26% /data
Стоит отметить, что по сравнению с моим первоначальным вопросом я удалил несколько файлов (отсюда и 28Gиспользование вместо 51G), но хорошо то, что и и duсообщают dfодно и то же значение :)
решение3
Ваша команда сортирует результаты от большего к меньшему. Наибольшее значение — этообщийпространство, используемое /data, а не пространство, которое он использовал сам по себе.