Понимание разреженных файлов, dd, поиск, структура блока индексного дескриптора

На работе мы используем разреженные файлы как часть внешней среды Oracle VM для изображений гостевых дисков. После некоторых вопросов от коллеги (с тех пор как я получил ответ) у меня осталось больше вопросов о разреженных файлах и, возможно, более широко о структуре inode – чтение man-страниц stat (2) и statfs (2) (на FreeBSD) I создайте впечатление, что я пойму более охотно, если бы знал больше C, но, увы, мои знания C минимальны в лучшем случае …

Я понимаю, что некоторые из них зависят от типа файловой системы. Меня больше всего интересуют UFS на FreeBSD / Solaris и ext4 – ZFS будет плюсом, но я не буду надеяться 🙂
Я регулярно пользуюсь Solaris 10, FreeBSD 10.3 и CentOS 6.7. Команды здесь выполняются на VMware CentOS 6.7, но с помощью FreeBSD были перекрестные ссылки. Если возможно, я заинтересован в получении понимания с точки зрения POSIX и предпочитаю FreeBSD поверх Linux, если это невозможно.

  • Сценарий удаленного резервного копирования SSH
  • Закрепить zip-файл как файловую систему только для чтения
  • Копирование файла, который записывается одновременно
  • Как определить размер блока файловой системы vxfs?
  • Как протестировать исправление файловой системы, выполненную fsck
  • Проверка целостности резервной копии dd
  • Рассмотрим следующий набор команд:

    printf "BIL" > /tmp/BIL dd of=/tmp/sparse bs=1 count=0 seek=10 dd if=/tmp/BIL of=/tmp/sparse bs=1 count=3 seek=10 dd if=/tmp/BIL of=/tmp/sparse bs=1 count=3 seek=17 dd of=/tmp/sparse bs=1 count=0 seek=30 dd if=/tmp/BIL of=/tmp/sparse bs=1 count=3 seek=30 

    Файл /tmp/BIL должен содержать содержимое (в шестнадцатеричном 4942 004c ) 4942 004c , поэтому, когда я hexdump файл /tmp/sparse я должен видеть, что эта комбинация повсюду:

     %>hexdump sparse 0000000 0000 4942 004c 0000 0000 4942 004c 0000 0000010 4200 4c49 0000 0000 0000 0000 0000 4942 0000020 004c 0000021 %>cat sparse BILBILBILBIL% 

    1. Почему второе появление «BIL» выглядит не по порядку? т.е. 4200 4c49 а не 4942 004c ? Это было написано третьей командой dd .

    2. Как известно cat и другим инструментам для печати в правильном порядке?

    Используя ls мы можем видеть пространство, которое предположительно используется, и выделенные блоки:

     %>ls -ls /tmp/sparse 8.0K -rw-r--r--. 1 bil bil 33 May 26 14:17 /tmp/sparse 

    Мы можем видеть, что предполагаемый размер составляет 33 байта, но размер выделенного файла составляет 8 килобайт (размер блока файловой системы – 4 КБ).

    3. Как такие программы, как ls различаются между «предполагаемым» размером и распределенным размером?

    Я задавался вопросом, была ли «предполагаемая» цифра, хранящаяся в индексном дескрипторе, в то время как выделенный размер был рассчитан путем перемещения прямых и косвенных блоков, хотя это не может быть правильным, поскольку вычисление через ходьбу потребует времени, и инструменты, такие как ls возвращаются быстро, даже для очень больших файлы.

    4. Какие инструменты я могу использовать для опроса информации inode?

    Я знаю stat , но, похоже, не распечатывает значения всех полей в inode …

    5. Есть ли инструмент, где я могу ходить прямо и косвенно?

    Было бы интересно увидеть каждый адрес на диске и содержимое, чтобы получить немного больше информации о том, как хранятся данные

    Если я запустил следующую команду после остальных, файл /tmp/sparse усечен:

     %>dd of=/tmp/sparse bs=1 count=0 seek=5 %>hexdump sparse 0000000 0000 4942 004c 0000005 

    6. Почему dd усекает мой файл и может ли dd или другой инструмент записывать в середину файла?

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

    7. Существуют ли механизмы для сокращения разреженных файлов? А если нет, то почему полезные файлы полезны?


    Хотя каждый вопрос выше может быть отдельным вопросом SO, я не могу их вскрывать, поскольку все они связаны с лежащим в основе пониманием.

  • Как увеличить размер файловой системы vfat до размера содержащегося раздела?
  • Клонирование жестких дисков и контрольные суммы без согласования
  • Лучше ли использовать cat, dd, pv или другую процедуру для копирования CD / DVD?
  • Не удалось подключить корневую файловую систему rw с журналом
  • DD с определенным рисунком
  • Монтаж только определенного пути файловой системы
  • One Solution collect form web for “Понимание разреженных файлов, dd, поиск, структура блока индексного дескриптора”

    Некоторые быстрые ответы: во-первых, вы не создали разреженный файл. Попробуйте эти дополнительные команды

     dd if=/tmp/BIL of=/tmp/sparse seek=1000 ls -ls /tmp/sparse 

    Вы увидите, что размер составляет 512003 байта, но занимает всего 8 блоков. Нулевые байты должны занимать целый блок и быть на границе блока, чтобы они были, возможно, разрежены в файловой системе.

    1. Почему второе появление «BIL» выглядит не по порядку?

      потому что вы находитесь в системе little-endian, и вы пишете вывод в шортах. Используйте байты, как это делает кошка.

    2. Как известно котятам и другим инструментам для печати в правильном порядке?

      они работают с байтами.

    3. Как такие программы, как ls, различаются между «предполагаемым» размером и распределенным размером?

      ls и т. д. используют системный вызов stat(2) который возвращает 2 значения:

       st_size; /* total size, in bytes */ blkcnt_t st_blocks; /* number of 512B blocks allocated */ 
    4. Какие инструменты я могу использовать для опроса информации об инодах?

      Стат хорош.

    5. Есть ли инструмент, где я могу ходить прямо и косвенно?

      На ext2 / 3/4 вы можете использовать hdparm --fibmap с именем файла:

       $ sudo hdparm --fibmap ~/sparse filesystem blocksize 4096, begins at LBA 25167872; assuming 512 byte sectors. byte_offset begin_LBA end_LBA sectors 512000 226080744 226080751 8 

      Вы также можете использовать debugfs :

       $ sudo debugfs /dev/sda3 debugfs: stat <1040667> Inode: 1040667 Type: regular Mode: 0644 Flags: 0x0 Generation: 1161905167 Version: 0x00000000 User: 127 Group: 500 Size: 335360 File ACL: 0 Directory ACL: 0 Links: 1 Blockcount: 664 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x4dd61e6c -- Fri May 20 09:55:24 2011 atime: 0x4dd61e29 -- Fri May 20 09:54:17 2011 mtime: 0x4dd61e6c -- Fri May 20 09:55:24 2011 Size of extra inode fields: 4 BLOCKS: (0-11):4182714-4182725, (IND):4182726, (12-81):4182727-4182796 TOTAL: 83 
    6. Почему dd усекает мой файл и может ли dd или другой инструмент записывать в середину файла?

      Да, dd может писать в середину. Добавьте conv=notrunc .

    7. Существуют ли механизмы для сокращения разреженных файлов? А если нет, то почему полезные файлы полезны?

      Нет. Потому что они занимают меньше места.

    Редкий аспект файла должен быть полностью прозрачным для программы, что иногда означает, что разреженность может быть потеряна, когда программа обновляет файл.

    Некоторые утилиты копирования имеют варианты сохранения разреженности, например tar --sparse , rsync --sparse .

    Обратите внимание: вы можете явно преобразовать упорядоченные нулевые блоки в файле в разреженность, используя cp --sparse=always и reverse, преобразование разреженного пространства в реальные нули, cp --sparse=never .

    Linux и Unix - лучшая ОС в мире.