Каталог, использующий больше пространства, чем ожидалось
У меня есть каталог на Ubuntu, которая содержит 262 144 файла. Каждый файл 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 в размере.
Править:
Благодаря полезным комментариям muru ниже, я решил, что каждый файл на самом деле использует 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 513 раз так), umount файловая система цикла, смонтируйте его по каталогу со всеми изображениями. Если это работает, umount это оттуда, удалите исходные изображения, отредактируйте /etc/fstab, таким образом, это монтирует петлевую файловую систему в правильном месте, mount -a, и Вы установлены.
Редактирование: можно использовать -b 1024 вместо 2048, также.
Различные части программного обеспечения сообщают о различной статистике использования дискового пространства 2 способами. Файлы могут иметь размер, который является числом байтов в файле и "физическим размером", который является суммой размеров кластера, используемых тем файлом. Физический размер или "размер кластера" является блоком минимума, который отслеживает ОС при обращении для интервала используемый на диске. Таким образом, если у Вас есть один файл, содержащий 1 байт, и Ваш размер кластера составляет 8 килобайтов, файл использует минимум 1 кластера, или 8 КБ.
Потраченное впустую дисковое пространство действительно не является обычно проблемой, как раз когда увеличение размеров диска и размеры кластеров увеличиваются до 32 КБ или 64 КБ.
guess my new question would be how to avoid each file using so much space?
Помещенные файлы, которые используются меньше в архивный файл, как .zip файл. ОС имеет предел на то, сколько кластеров она может отслеживать.
, Возможно, кто-то еще может объяснить предел на размеры кластера для нескольких OSS