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

Question

Мне интересно, как команда stat вычисляет блоки файла. Я прочитал article, он говорит:

Значение st_blocks дает размер файла в 512-байтных блоках. (Это может быть меньше, чем st_size/512, например, когда файл имеет отверстия.) Значение st_blksize дает «предпочтительный» размер блока для эффективного ввода/вывода файловой системы. (Запись в файл в более мелких фрагментах может привести к неэффективной read-modify-rewrite.)

, но я не могу проверить его на своем тесте.

мой файловая система ext3.

в dumpe2fs -h/DEV/sda3 показывает:

... 
First block: 0 
Block size: 4096 
Fragment size: 4096 
... 

тогда я бегу

kent@KentT60:~/Desktop$ stat Email 
File: `Email' 
Size: 965 Blocks: 8 IO Block: 4096 regular file 
Device: 80ah/2058d Inode: 746095 Links: 1 
Access: (0644/-rw-r--r--) Uid: (1000/ kent) Gid: (1000/ kent) 
Access: 2009-08-11 21:36:36.000000000 +0200 
Modify: 2009-08-11 21:36:35.000000000 +0200 
Change: 2009-08-11 21:36:35.000000000 +0200 

Если блоки здесь означает: сколько 512bytes блоков, число должно быть 2 не 8. Я подумал, что размер блока из файловой системы (io-блок) равен 4k. Если fs получит файл электронной почты, он будет извлекать минимальные 4k с диска (блоки размером 8 x 512 байтов), что означает 965/512 + 6 = 8. Я не уверен, правильна ли догадка.

еще одно испытание:

kent@KentT60:~/Desktop$ stat wxPython-demo-2.8.10.1.tar.bz2 
File: `wxPython-demo-2.8.10.1.tar.bz2' 
Size: 3605257 Blocks: 7056 IO Block: 4096 regular file 
Device: 80ah/2058d Inode: 746210 Links: 1 
Access: (0644/-rw-r--r--) Uid: (1000/ kent) Gid: (1000/ kent) 
Access: 2009-08-12 21:45:45.000000000 +0200 
Modify: 2009-08-12 21:43:46.000000000 +0200 
Change: 2009-08-12 21:43:46.000000000 +0200 


3605257/512=7041.xx = 7042 

после моей догадке выше, это будет 7042 + 6 = 7048. но результат стат показывает 7056.

И еще один пример из Интернета на http://www.computerhope.com/unix/stat.htm. Я скопирую пример внизу страницы здесь:

File: `index.htm' 
Size: 17137 Blocks: 40 IO Block: 8192 regular file 
Device: 8h/8d Inode: 23161443 Links: 1 
Access: (0644/-rw-r--r--) Uid: (17433/comphope) Gid: (32/ www) 
Access: 2007-04-03 09:20:18.000000000 -0600 
Modify: 2007-04-01 23:13:05.000000000 -0600 
Change: 2007-04-02 16:36:21.000000000 -0600 

В этом примере размер блока FS равен 8k. Я полагаю, что число блоков должно быть 16xN, но 40. заблудились ...

кто может объяснить, как стат вычислят блоки?

Спасибо!

Answer 1

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

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

Итак, для вашего примера «Email» с размером 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) 

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

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

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

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

Ну, вот файл с 4 байта в нем - так же, как test - но он использует 32.5K физически на диске, из-за как файловая система ZFS выделяет пространство. Размеры блоков увеличиваются по мере увеличения размера файла, но они не уменьшаются при уменьшении размера файла. (И да, это может привести к значительным потерянным местам в зависимости от типов файлов и операций с файлами, которые вы делаете в ZFS, поэтому он позволяет вам установить максимальный размер блока на основе каждой файловой системы и динамически изменять его.)

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