ext4: каталог берет 250 ГБ вместо 20 ГБ?

у меня есть хинду ядро linux x64 2.6.32 хинду r1 использующий ext4

у меня есть диск на 260 ГБ, и кажется, что взяты 99%.

(ufk мой корневой каталог),

du -hl --max-depth=1 ufk

вывод показывает много каталогов и их размеров и в конце:

231G    ufk

я суммировал весь размер каталогов, которые он показывает, и он не подходит к 20 ГБ

df -i ufk

Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/root            18317312  759944 17557368    5% /

du -hsl ufk  

231G    ufk

какие-либо идеи, какова причина

1
задан 06.01.2010, 15:54

4 ответа

я думаю, что это была связанная ошибка ext4. я решил вопрос путем копирования всего содержания/home/ufk /* к другому разделу, удаления и воссоздания/home/ufk каталога и копирования всех файлов назад.

1
ответ дан 12.12.2019, 08:03

"-i"возвращает inode числа (количество "записей" в "каталоге файлов"), не размер блока (пространство, использованное файлами).

Это подтверждено заголовком "df": Inodes IUsed IFree IUse% Отметьте "I" перед каждым числом.

Удалите"-i"и это должно дать Вам корректные числа. Используйте"-hk"поскольку человекочитаемые числа и размер блока выражаются в килобайтах.

4
ответ дан 12.12.2019, 08:03

Вероятно, ufk смонтирован по каталогу, который содержит 250 ГБ данных.Действительно, df показывает использование файловой системы на точку монтирования.

Пример:

mkdir tmp
dd if=/dev/urandom of=tmp/file bs=512 count=4096
mount /dev/sda5 tmp

теперь tmp ничего не должен содержать (принятие sda5 чистый раздел, и т.д.), но каталог перед монтированием содержит a file из случайных данных.

0
ответ дан 12.12.2019, 08:03

Хорошо, этот вопрос является древним, но с другой стороны я пропускаю значок Некроманта... :-)

Я встречался с этим видом фантомного использования диска несколько раз. Почти каждый раз это было то, потому что некоторый процесс все еще использовал - или имел дескриптор файла, открытый для - некоторый удаленный, огромный файл. Если процесс все еще будет держать свои руки на некоторый файл, как огромный файл журнала, то файл не будет на самом деле удален, пока процесс не позволяет ему пойти.

Можно определить этот вид файлов, например, с lsof -n | grep -i deleted и затем перезапустите незаконный процесс (или большую часть времени, просто отправьте Сигнал HUP в него с killall -HUP someprocessname

2
ответ дан 12.12.2019, 08:03

Теги

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