Каталог использует больше места, чем ожидалось
У меня есть каталог на Ubuntu, который содержит 262144 файлов. Каждый файл представляет собой изображение размером 25x25 png. В среднем эти файлы составляют приблизительно 1,14 КБ, и ни один файл не превышает 2 КБ. Тем не менее, этот каталог занимает 3,1 ГБ дискового пространства. Как это возможно? По моим расчетам этот каталог должен использовать 262144 * 1140 = 298844160 bytes, который является только 0.298844 GB,
Вот шаги, которые я следовал, чтобы получить эту информацию.
Я побежал ls -1 -f | wc -l посчитать количество файлов в каталоге. Это возвращает 262146 (То есть, 262144 + 1 + 1 за . а также ..).
Затем я побежал find . -size +2k и результат был просто .,
Наконец я побежал du -sh culprit_directory и результат показывает 3.1G culprit_directory,
Я думаю, что может произойти две вещи:
- Ubuntu требуется дополнительное пространство для хранения каталога, который содержит очень большое количество очень маленьких файлов. Возможно, но целый порядок?
- Я делаю ошибку в моих расчетах, и это ожидаемый размер каталога. Также возможно, но я не могу увидеть, где я сделал эту ошибку.
Если бы кто-то с большим опытом работы с внутренним хранилищем файлов Ubuntu мог бы посоветовать мне, я был бы очень признателен.
РЕДАКТИРОВАТЬ: я добавил один из файлов PNG. Этот 591 bytes по размеру.
РЕДАКТИРОВАТЬ:
Благодаря полезным комментариям ниже, я определил, что каждый файл на самом деле использует 12KB на диске, даже если он состоит всего из нескольких сотен байтов. Используя новые номера, получаем 262144 * 12000 = 3145728000, что дает нам 3.145728GB,
Думаю, мой новый вопрос будет состоять в том, как избежать использования каждого файла так много места?
2 ответа
Отвечая на дополнительный вопрос, вероятно, в этих случаях проще всего создать небольшую специальную файловую систему и смонтировать ее. Что-то вроде этого:
$ dd if=/dev/zero of=imgdisk.img bs=1M count=512
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 0.425628 s, 1.3 GB/s
$ du -h imgdisk.img
513M imgdisk.img
$ mkfs.ext4 -b 2048 imgdisk.img
mke2fs 1.42.12 (29-Aug-2014)
Discarding device blocks: done
Creating filesystem with 262144 2k blocks and 32768 inodes
Filesystem UUID: 8837a733-6b75-4326-bb72-9372538653ad
Superblock backups stored on blocks:
16384, 49152, 81920, 114688, 147456
Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
$ mkdir imgmount
$ sudo mount imgdisk.img imgmount -o loop
$ ls imgmount/
lost+found
скопируйте туда изображения (размер которых может быть слишком мал для ваших файлов; сделайте 512 a 513, если это так), umount файловая система цикла, смонтируйте ее над каталогом со всеми образами. Если это работает, umount это оттуда, удалить оригинальные изображения, редактировать /etc/fstab поэтому он монтирует петлевую файловую систему в нужном месте, mount -a и все готово
Изменить: вы можете использовать -b 1024 вместо 2048 тоже.
Разные программы сообщают о разной статистике использования дискового пространства двумя способами. Файлы могут иметь размер, который представляет собой число байтов в файле, и "физический размер", который представляет собой сумму размеров кластера, используемого этим файлом. Физический размер, или "размер кластера" - это минимальный блок, который ОС отслеживает при обращении к пространству, используемому на диске. Таким образом, если у вас есть один файл, содержащий 1 байт, и размер кластера составляет 8 килобайт, файл использует минимум 1 кластер или 8 КБ.
Потерянное дисковое пространство обычно не является проблемой, даже если размеры дисков увеличиваются, а размеры кластеров увеличиваются до 32 или 64 КБ.
guess my new question would be how to avoid each file using so much space?
Поместите файлы, которые используются меньше, в архивный файл, например файл.zip. ОС имеет ограничение на количество кластеров, которые она может отслеживать.
Может быть, кто-то еще может объяснить ограничение размера кластера для нескольких ОС.