ext4, почему 70k-файл занимает 88 блоков

[root@xx]# cat -n create_extents.sh 1 #!/bin/bash 2 3 if [ $# -ne 2 ] 4 then 5 echo "$0 [filename] [size in kb]" 6 exit 1 7 fi 8 9 filename=$1 10 size=$2 11 i=0 12 13 while [ $i -lt $size ] 14 do 15 i=`expr $i + 7` 16 echo -n "$i" | dd of=$1 bs=1024 seek=$i 17 done 

так я и сделал

 sudo ./create_extents.sh /device3/test70 70 

Затем я использую команду debugfs «stat», чтобы проверить ее,

Inode: 13 Тип: обычный Режим: 0644 Флаги: 0x80000

 Generation: 2638566511 Version: 0x00000000:00000001 User: 0 Group: 0 Size: 71682 File ACL: 0 Directory ACL: 0 Links: 1 Blockcount: 88 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x53292990:042e685c -- Wed Mar 19 01:22:24 2014 atime: 0x5329298f:edd4dc60 -- Wed Mar 19 01:22:23 2014 mtime: 0x53292990:042e685c -- Wed Mar 19 01:22:24 2014 crtime: 0x5329298f:edd4dc60 -- Wed Mar 19 01:22:23 2014 Size of extra inode fields: 28 EXTENTS: (ETB0):33803, (1):33825, (3):33827, (5):33829, (7-8):33831-33832, (10):33834, (12):33836, (14-15):33838-33839, (17):33841 (END) 

Почему так много блоков? и место настолько разбросано ..? Размер моего блока – 4k. Я знаю, что ext4 пытается удержать локаль для одного файла.

благодаря

One Solution collect form web for “ext4, почему 70k-файл занимает 88 блоков”

Значение «Blockcount» является полем struct ext2_inode . Это значение, которое возвращается в syscall stat в поле st_blocks . По историческим причинам единица этого поля составляет 512-байтовые блоки – это был размер блока файловой системы на ранних файловых системах Unix, но теперь это просто произвольная единица. Вы можете видеть, что значение увеличивается и уменьшается в зависимости от размера файла в fs/stat.c

Вы можете увидеть это же значение, запустив stat /device3/test70 («Блоки: 88»).

Фактически файл содержит 18 блоков, что, как ожидается, с размером блока 4 КБ (файл имеет длину 71682 байта, а не разрежен и 17 × 4096 \ <71682 ≤ 18 × 4096).

Вероятно, удивительно, что число 512-байтовых блоков составляет 88, а не 141 (потому что 140 × 512 \ <71682 ≤ 141 × 512) или 144 (что составляет 18 × 4096/512). Причина связана с вычислением в fs/stat.c которым я связан выше. Ваш скрипт создает этот файл, многократно i_blocks за конец, а для i_blocks поля i_blocks файл разрежен – есть целые 512-байтовые блоки, которые никогда не записываются и, следовательно, не учитываются в i_blocks . (Тем не менее, нет никакого блока памяти, который полностью искал прошлый, так что файл на самом деле не разрежен.)

Если вы скопируете файл, вы увидите, что в копии есть 144 таких блока, как ожидалось (обратите внимание, что вам нужно запустить cp --sparse=never , потому что GNU cp пытается быть умным и ищет, когда видит пространства нулей).

Что касается количества экстентов, то создание файла таким образом, как вы делаете последовательные попытки в конце, не является ситуацией, для которой оптимизируются файловые системы. Я думаю, что эвристика в драйвере файловой системы сначала решит, что вы создаете небольшой файл, поэтому начинайте с резервирования пространства по одному блоку за раз; позже, когда файл растет, эвристика начинает резервировать несколько блоков за раз. Если вы создаете более крупный файл, вы должны увидеть увеличение больших экстентов. Но я не знаю ext4 достаточно подробно, чтобы быть уверенным.

  • Один и тот же файл с различным содержимым на каждом прочитанном
  • Что делает fsck -p (preen) на ext4?
  • Ext4: ошибки ввода-вывода на чистом внешнем диске
  • Повторяющиеся ошибки ext4 «плохой заголовок недействительной магии» на здоровом диске
  • selinux на squashfs с overlayfs
  • fsck не будет fsck (невозможно установить флаги суперблока)
  • ext4 сообщил, что чист с помощью fsck после жесткого сброса: это нормально?
  • Почему fstrim обрезает все свободное пространство на моем зеркале mdraid после перезагрузки?
  • Некоторая документация для процесса «ext4-rsv-convert»?
  • ext4 переопределяет мой параметр commit = 100 mount с фиксацией = 0
  • jbd2 журнал константа i / o
  • Linux и Unix - лучшая ОС в мире.