.png)
Я немного озадачен тем, как отчеты ext4 используют пространство. На новой установке Debian wheezy (тестирование) я постоянно получал около 1 ГБ дополнительного пространства, используемого с 60 ГБ SSD, по сравнению с du. Затем я загрузил этот компьютер по сети и смонтировал SSD. Загруженная по сети ОС (Debian squeeze) показывает только 180 МБ дополнительного пространства, используемого на SSD. Журнал составляет 128 МБ, так что больше ничего не осталось.
О каком дополнительном используемом пространстве сообщает df, когда это не пространство, зарезервированное для корневых или удаленных файлов? Использование Google в основном приводит к тем обычным причинам, которые я исключил. И почему этот объем отличается в одной и той же файловой системе при монтировании в разных операционных системах? Я проверил это путем повторной установки, и дополнительное использование снова составило ~1 ГБ при установке wheezy и 180 МБ, когда я загрузился по сети и смонтировал этот SSD.
На XFS и btrfs дополнительное сообщаемое использование кажется незначительным. Я понимаю, что файловой системе нужны некоторые накладные расходы, но это неудобно, когда эти накладные расходы смешиваются с реальным использованием.
Вот некоторые подробные результаты.
дф
$ df -m on wheezy
Filesystem 1M-blocks Used Available Use% Mounted on
rootfs 57132 1567 52703 3% /
udev 7899 0 7899 0% /dev
tmpfs 1581 1 1581 1% /run
/dev/mapper/ssd-kvmhost 57132 1567 52703 3% /
tmpfs 5 0 5 0% /run/lock
tmpfs 3162 0 3162 0% /tmp
tmpfs 3162 0 3162 0% /run/shm
ду
$ du -sm /
592 /
tune2fsпоказывает количество инодов 3670016 и размер 256, что действительно объясняет почти все используемое пространство. Я просто не понимаю, почему это не вычитается из размера, поскольку иноды статически зарезервированы. Считать это как пространство, а затем всегда считать это как используемое, не имеет особого смысла.
Вот вывод для той же файловой системы из загруженного по сети Debian Squeeze:
aufs 7905 46 7859 1% /
tmpfs 7905 0 7905 0% /lib/init/rw
udev 7900 1 7900 1% /dev
tmpfs 7905 1 7905 1% /dev/shm
172.17.172.127:/storage/private/tftp/debian-live-6.0.3-amd64-lxde-desktop
24737 17448 7289 71% /live/image
tmpfs 7905 46 7859 1% /live/cow
tmpfs 7905 0 7905 0% /live
tmpfs 7905 1 7905 1% /tmp
/dev/mapper/ssd-kvmhost
56337 772 52703 2% /mnt
И просто для подтверждения, du -sm / по сети загрузил ОС:
592 /
Может быть, старое ядро благоразумно не считает статически зарезервированное пространство inode пригодным для использования и, таким образом, не должно показывать его как используемое? Разница составляет 795 МБ как в Size, так и в Used, почти все пространство, необходимое для inode. Что же тогда такое 180 МБ? Если это тоже статично, не будет ли оптимальным также вычесть это из Size? Тогда dfможно было бы фактически показать реальное использование, как, похоже, делают другие файловые системы.
Как я это вижу, если моей файловой системе требуется статическое количество накладных расходов, то она просто предоставляет меньше полезного пространства, чем некоторые другие файловые системы для того же количества абсолютного пространства. Разве df не должен отражать это, а также показывать, сколько изполезное пространствоЯ использовал?
решение1
ext[234] по умолчанию резервирует 8192 inode на группу блоков размером 128 МБ, что занимает 2 МБ на группу, что составляет около 1 ГБ для файловой системы размером 60 ГБ. Не должно быть никакой разницы, если вы смонтируете диск в другой системе. Похоже, они могли изменить способ, которым ядро сообщает об использованном пространстве между wheezy и squeeze, хотя я пока не нашел коммита, указывающего на то, что это было сделано намеренно.
решение2
На ваш вопрос было бы легче ответить, если бы вы предоставили вывод df и du.
Но это очень похоже на df говорит, что у меня занято на 20G больше места на диске, чем du. Почему?
По сути, ваша файловая система использует часть диска для собственных метаданных, т. е. не для самих файлов, а для отслеживания файлов, их имен, разрешений, их расположения на диске и т. д.
Как говорится в ответе, ссылку на который я привел выше, запуск tune2fs -l <device name>покажет вам больше информации. В частности, inode countx inode sizeдолжен быть близок к разнице между dfи du.
Опять же, основываясь на предыдущем ответе, корневой раздел моей системы использует около 1,77% диска для инодов. 60 ГБ * 0,0177 ~= 1 ГБ.
Я подозреваю, что цифра в 180 МБ неверна, но не могу быть уверен без дополнительных подробностей, например, вывода mountна вашей сетевой загруженной системе. Например, это может быть из-заminixdf/bsddfвариант крепления.