Почему результаты du и квоты не соответствуют?

Я смог починить свой собственный dracut модуль, который добавляет dropbear к initramfs и запускает его во время init. Это также заменяет cryptroot-спросить сценарий от модуля dracut-склепа (который просит у Вас Ваш пароль LUKS) с пользовательским, который сидит без дела и ожидает Вас для разблокирования файловой системы самих (например, по SSH) (а также немного дополнительного hocus).

Я поднял его на битоприемнике, если кто-либо хочет использовать или улучшить его. Это в настоящее время не завершает работу dropbear сервера после начальной загрузки, таким образом, это - вероятно, что-то, что могло быть улучшено.

8
22.09.2014, 21:26
2 ответа

Я полагаю, что некоторые файлы все еще остаются открытыми некоторыми процессами. Вы можете попытаться перечислить их, используя,

lsof | grep username | grep deleted

Лучше использовать версию,

lsof +L1 | grep username

Однако иногда может быть несоответствие в выводе между du и quota , что объясняется в этой ссылке . Выдержка из ссылки

В Unix команды du и quota могут сообщать разные значения. В причина этого несоответствия в том, что процесс, который проходит через файловая система, проверяет квоты и обновляет таблицы использования, работает только в конкретное время. Таким образом, между проверками квот будут периоды. что команда quota -v сообщит о неправильном использовании диска. Используйте du команда для наиболее точной информации о размере вашего файлы.

2
27.01.2020, 20:13

Квота работает, запросивая файловую систему для блоков, фактически занятых вашими файлами.

du работает путем сканирования каталогов рекурсивно для ваших файлов.

Два метода могут дать разные результаты. Например, когда вы «удалите» файл, то он больше не виден при перечислении каталога. Тем не менее, блоки на диске на самом деле не освобождены до последнего файлового файла на нем не закрыто. В этом случае файл невидим для du , но все равно подсчитывается против вашей квоты.

2
27.01.2020, 20:13

Теги

Похожие вопросы