Центр информации по операционным системам: Контент / Статьи / Дисковая структура ReiserFS

Добро пожаловать,

Свежие материалы

Производительность программных RAID-массивов из разных дисков в Linux
bullet

Лицензия раздора
bullet

Патч Reiser4 для Linux 2.6.22
bullet

Подготовка к экзамену LPI Linux.
bullet

Архитектура файловой системы UFS2

Обсуждения

Микропроцессор "Эверест" (1)
bullet

Запрет регистрации на osrc.info (1)
bullet

Ответ Javе и Flash'у (70)
bullet

Новая программа поддержки от Microsoft (2)
bullet

Solaris будет портирован на Itanium и POWER? (3)
bullet

9 декабря вышла новая сборка Xameleon (9)
bullet

рассылка (2)
bullet

ЗРОС (3)

Новый стиль OSRC.info (2)
bullet

Обсуждение статьи "Взгляд на развитие YellowTAB" (124)

В Сети

Гостей: 4, Пользователей: 0 ...

рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07

Пользователей: 1007
Новичок: alicemokas

Дисковая структура ReiserFS

на Понедельник, 31 Октябрь 2005, 12:48
добавил: Пешеходов А. П. aka fresco

категория Статьи
комментарии: 0
просмотров: 5190

Листья

Листья находятся на самом нижнем уровне S+ дерева. Все данные содержаться внутри самого узла (исключая данные, адресуемые косвенной записью и располагающиеся в неформатированнх узлах (или блоках, unformated nodes). Листья представлены заголовком блока, заголовками записей и собственно записями.



___________________________________________________

|             | Массив     |           |           |

| Заголовок   | заголовков | Свободное | Массив    |

| блока       | записей    | место     | записей   |

|             | [0-n]      |           | [n-0]     |

|_____________|____________|___________|___________|

Примечательно, что свободное пространство в блоке расположено между последним заголовком записи и первой записью (т.е. записи идут в обратном порядке). Таким образом, новый заголовок записи и сама запись могут быть довольно просто добавлены в лист без его перегруппировки Заметьте также, что записи имеют переменную длину.

Заголовки записей

Заголовок записи содержит ключ, смещение записи в листе и ее размер.

См. include/linux/reiser_fs.h



struct item_head {

 struct reiserfs_key ih_key;

 union {

 __le16 ih_free_space_reserved; /* Количество свободных байт в последнем

        неформатированнм узле для косвенной записи , 0xffff для прямой и

        stat-записи */

 __le16 ih_entry_count; /* Количество элементов каталога для директорной записи */

 } u;

 __le16 ih_item_len; /* Размер записи */

 __le16 ih_item_location; /* Смещение начала записи в блоке */

 __le16 ih_version; /* 0 для всех старых записей, 2 для новых. Старший бит

        устанавливается fsck на время выполнения */

};

В комментариях к определению этой структуры сказано, что поле ih_version равно 2 для всех новых записей. Однако константа KEY_FORMAT_3_6, используемая для инициализации поля, определена как 1.

Записи

Запси (items) наконец содержат собственно данные. Существует 4 типа записей: stat-записи, записи каталога, прямые и косвенные записи. Файл может быть представлен одной или несколькими прямыми или косвенными записями – в зависимости от его размера. Каждому файлу или директории предшествует stat-запись.

Stat-items

Stat-запись содержит метаданные для файлов и директорий. Ключи, принадлежащие stat-записи, имеют нулевые поля offset и type что бы всегда располагаться впереди других записей, принадлежащих тому же самому “номеру inode”. По тем же причинам, по которым в reiserfs существуют 2 версии ключей, поддерживаются также и 2 версии stat item. В новой версии поле size увеличено с 32-х до 64-х бит, а также, по некоторым причинам, были увеличены размеры полей, отвечающих за хранение количества жестких ссылок, user ID и group ID – с 16-ти до 32-х бит. Размер самого stat item увеличился с 32-х байт в первой версии до 44-х во второй.

См. include/linux/reiserfs_fs.h



/* Старая версия stat data размером 32 байта */

struct stat_data_v1 {

 __le16 sd_mode; /* Тип и права доступа к файлу */

 __le16 sd_nlink; /* Количество жестких ссылок */

 __le16 sd_uid; /* Владелец (owner) */

 __le16 sd_gid; /* Группа (group) */

 __le32 sd_size; /* Размер файла */

 __le32 sd_atime; /* Времы последного доступа */

 __le32 sd_mtime; /* Время последней модификации */

 __le32 sd_ctime; /* Время последней модификации stat data */

 union {

 __le32 sd_rdev; /* Номер устройства */

 __le32 sd_blocks; /* Количество выделенных файлу блоков */

 } u;

 __le32 sd_first_direct_byte; /* Смещение первого байта файла, хранимого в прямой

        записи: если 1 – это символическая ссылка, если (__u32)0 – это не

        прямая запись. Существование этого поля меня реально достало

        (grates). Заменим его вместе с макросами, основанными на sd_size и

        нашей политикой запрещение хвостов (tail supression policy,

        очевидно имеется в виду механизм, стоящий за опцией notail – пер.)

        Когда-нибудь. Ганс.*/

};



/* Дисковый stat item (наша версия дискового inode UFS за вычетом адресных блоков */

struct stat_data {

 __le16 sd_mode; /* Тип и права доступа к файлу */

 __le16 sd_attrs; /* Inode флаги */

 __le32 sd_nlink; /* Количество жестких ссылок */

 __le64 sd_size; /* Размер файла */

 __le32 sd_uid; /* owner */

 __le32 sd_gid; /* group */

 __le32 sd_atime; /* ... */

 __le32 sd_mtime; /* ... */

 __le32 sd_ctime; /* ... */

 __le32 sd_blocks; /* количество блоков, выделенных файлу */

 union {

 __le32 sd_rdev; /* Номер устройства */

 __le32 sd_generation; /* Поколение файла */

 } u;

};

Поле sd_mode – битовая маска в стиле struct stat. Только регулярные файлы и каталогии имеют другие записи, ассоциированныесо stat item. Во всех других случаях (сокет, символическая ссылка, блочное и символьное устройство, а также FIFO) stat item представляет собой все содержимое файла.

Поле sd_rdev применяется для специальных файлов. Оно хранит номер устройства (или сокета). sd_generation примеятся во всех других случаях и означает поколение inode для файла/каталога/ссылки. Поле sd_first_direct_byte, как и хотел Hans Reiser, во второй версии более не используется.

Directory items

Запись каталога описывает директорию. Если каталог имеет слишком много элементов и не умещается в одной записи, он разбивается на несколько directory items. Directory item состоит из 2-х массивов: заголовков элементов каталога и имен файлов, растущих к середине.

См. include/linux/reiserfs_fs.h



struct reiserfs_de_head {

 __le32 deh_offset; /* Третий компонент ключа элемента каталога – значение хэша и

        номер поколения */

 __le32 deh_dir_id; /* Object ID родительского каталога */

 __le32 deh_objectid; /* Object ID данного элемента */

 __le16 deh_location; /* Смещение имени файла в данной записи */

 __le16 deh_state; /* Бит 1 указывает, что этот элемент содержит stat- data

        (не используется; бит 2 – элемент доступен (1) или скрыт (0) */

};

Имя файла – простая ASCII строка, заканчивающаяся нулем. Поле offset просто неверно названо – оно содержит значение хэша для имени файла. Биты [7-30] – это хэш, [0-6] – поколение для файлов с одинаковым хэшем, бит 31 не используется. Хэш используется в reiserfs для поиска имен файлов и каталогов, отсортированныхпо полю offset. В настоящий момент доступны 3 хэш-функции: keyed tea хэш, rupasov-хэш и r5-хэш. Задача хэш-функции – генерировать разные значения для разных строк с как можно меньшим количеством коллизий. В Linux-реализации reiserfs по умолчанию используется r5-хэш.

индекс статьи
страница 1 : страница без заголовка
страница 2 : страница без заголовка
страница 3 - текущая : страница без заголовка
страница 4 : страница без заголовка