Как команда статистики вычисляет блоки файла?

Как я вспоминаю, единственный портативный способ сделать это, должен бросить результат к "неподписанному длинному целому" и использованию %lu.

printf("sizeof(int) = %lu", (unsigned long) sizeof(int));
10
задан Kent 28 August 2009 в 12:51
поделиться

1 ответ

Инструмент командной строки stat использует функции stat / fstat и т. Д., Которые возвращают данные в формате ] stat структура. Член st_blocks структуры stat возвращает:

Общее количество физических блоков размером 512 байт, фактически размещенных на диске. Это поле не определено для специальных блочных файлов или специальных символьных файлов.

Таким образом, для вашего примера «Электронная почта», с размером 965 и количеством блоков 8, это означает, что 8 * 512 = 4096 байт физически выделяются на диск. Причина, по которой это не 2, заключается в том, что файловая система на диске не выделяет пространство в единицах 512, она, очевидно, выделяет их в единицах 4096. (И единица распределения может варьироваться в зависимости от размера файла и сложности файловой системы. Например, ZFS поддерживает разные единицы распределения.)

Аналогично, для примера wxPython он указывает, что на диске физически выделено 7056 * 512 байтов или 3612672 байта. Вы уловили идею.

Размер блока ввода-вывода - это «подсказка относительно« наилучшего »размера единицы для операций ввода-вывода» - обычно это единица распределения на физическом диске. Не запутайтесь между блоком ввода-вывода и блоком, который stat использует для обозначения физического размера; блоки для физического размера всегда составляют 512 байт.

Обновление на основе комментария:

Как я уже сказал, st_blocks - это то, как ОС указывает, сколько места используется файлом на диске. Фактические единицы размещения на диске - это выбор файловой системы. Например, ZFS может иметь блоки распределения переменного размера даже в том же файле , из-за способа распределения блоков: файлы начинаются с небольшого размера блока, и размеры блоков продолжают увеличиваться, пока не достигнут определенной точки. Если позже файл будет усечен, он, вероятно, сохранит старый размер блока. Таким образом, в зависимости от истории файла он может иметь несколько возможных размеров блока. Таким образом, учитывая размер файла, не всегда очевидно, почему он имеет определенный физический размер.

Конкретный пример: на моем компьютере Solaris с файловой системой ZFS я могу создать очень короткий файл:

$ echo foo > test
$ stat test
  Size: 4               Blocks: 2          IO Block: 512    regular file
(irrelevant details omitted)

Хорошо, маленький файл , 2 блока, использование физического диска для этого файла составляет 1024.

$ dd if=/dev/zero of=test2 bs=8192 count=4
$ stat test2
  Size: 32768           Blocks: 65         IO Block: 32768  regular file

Хорошо, теперь мы видим использование физического диска 32,5 КБ и размер блока ввода-вывода 32 КБ. Затем я скопировал его в test3 и усек этот файл test3 в редакторе:

$ cp test2 test3
$ joe -hex test3
$ stat test3
  Size: 4               Blocks: 65         IO Block: 32768  regular file

Итак, вот файл с 4 байтами - точно так же, как test - но это' s физически использует 32,5 КБ на диске из-за того, как файловая система ZFS выделяет пространство. Размеры блоков увеличиваются при увеличении файла, но не уменьшаются при уменьшении файла. (И да, это может привести к значительной потере места в зависимости от типов файлов и файловых операций, которые вы выполняете в ZFS, поэтому он позволяет вам устанавливать максимальный размер блока для каждой файловой системы и изменять его динамически.)

Надеюсь, теперь вы поймете, что не всегда существует простая связь между размером файла и использованием физического диска. Даже из приведенного выше неясно, почему 32,5 КБ необходимы для хранения файла размером ровно 32 КБ - похоже, что ZFS обычно требуется дополнительные 512 байтов для собственного дополнительного хранилища. Возможно, он использует это хранилище для контрольных сумм, счетчиков ссылок, состояние транзакции - бухгалтерия файловой системы. Включая эти дополнения в указанный физический размер файла, кажется, что ZFS пытается не вводить пользователя в заблуждение относительно физической стоимости файла. Это не означает, что обратное проектирование вычислений является тривиальным делом, не зная подробностей о реализации базовой файловой системы.

18
ответ дан 3 December 2019 в 20:43
поделиться
Другие вопросы по тегам:

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