Конкретные файловые системы - TriaFS, FAT, EXT
Вся башня теперь стоит - VDS маршрутизирует, VFS разрешает пути, абстрактный слой перенаправляет, слой разделов находит области, слой Storage достаёт секторы а IDE или AHCI говорят с железом. Один вопрос оставался открытым всё это время, что же собственно лежит на этих секторах? Как из сырых 512-байтовых блоков получаются файлы и каталоги? За это отвечают конкретные файловые системы и в моей системе их пять: TriaFS, FAT и EXT для чтения и записи, ISO9660 и CDDA только для чтения. Все в разной степени готовности.
Один вопрос, три ответа
По сути все решают одну задачу: "файл состоит из многих блоков, разбросанных по диску, как найти их все в правильном порядке?" И именно здесь три файловые системы идут разными путями.
- FAT создает одну большую таблицу, FAT (File Allocation Table). Это связный список в виде таблицы в которой запись 5 говорит "дальше в 6", запись 6 говорит "дальше в 9", запись 9 говорит "конец". Файл, таким образом, это цепочка кластеров, а каталог, это список записей по 32 байта с именем, первым кластером и размером.
- EXT файловая система Linux, использует иноды. Инод, это узел с метаданными файла и указателями на его блоки данных (напрямую и обходными путями также косвенно). Диск разбит на блок-группы, у каждой свои битовые карты и таблица инодов.
- TriaFS использует похожие с EXT структуры (инод - узел с метаданными файла и указателями на его блоки данных), но реализует внутреннюю логику динамически.
Четыре макета на диске
Эти различия видны, если посмотреть на диск от начала к концу. FAT начинается с загрузочного сектора и BPB, затем таблицы FAT, корневой каталог, а большой остаток, это кластеры данных. EXT открывается суперблоком и затем нанизывает блок-группы, каждая, это маленькая файловая система сама по себе. А у ISO9660 своя особенность: первые шестнадцать секторов зарезервированы, лишь в секторе 16 стоит primary volume descriptor с корнем, и сектор здесь, это 2048 байт вместо 512.
Два мира FAT и суперблок EXT
Каждая файловая система держит во время работы небольшую информационную структуру на раздел, кэшируя ровно то, что нужно из загрузочного сектора или суперблока. У FAT хорошо видно, сколько формат тащит с собой:
struct fat_specific_info_t {
uint16_t bytes_per_sector; // 512, 1024, ...
uint32_t fat_table_first_sector; // где начинается таблица FAT
uint16_t cluster_size_in_sectors;
uint32_t number_of_clusters; // определяет FAT12 / 16 / 32
uint32_t root_directory_location; // сектор (FAT12/16) или кластер (FAT32)
Spinlock cluster_alloc_lock, fat_cache_lock, file_chain_lock; // блокировки FAT
};
Число кластеров, кстати, решает FAT12, FAT16 или FAT32. Один код - три разновидности. EXT же выдаёт себя магией и целым рядом структурных чисел в суперблоке, тех же что и проба раздела уже использовала для проверки правдоподобия.
struct ext_superblock_t {
uint32_t total_inodes, total_blocks;
uint32_t blocks_per_group, inodes_per_group;
uint16_t inode_size;
uint16_t ext_signature; // 0xEF53
/* ... */
};
Общий договор (interface)
Как ни различны эти пять внутри, снаружи они выглядят одинаково. Каждая исполняет один и тот же договор (interface) из статьи про абстрактный слой: triafs_read_file, fat_read_file, ext_read_file и так далее, все с одной сигнатурой и одними кодами FS_ERROR_*. Именно поэтому switch в абстрактном слое был так короток, и именно поэтому VFS так и не узнаёт, с чем говорит.
Каждая из записываемых файловых систем к тому же несёт свою иерархию блокировок, на раздел. FAT, например, запирает строго в порядке cluster_alloc_lock -> fat_cache_lock -> file_chain_lock -> directory_lock, EXT в порядке inode_bitmap_lock -> block_bitmap_lock -> inode_cache_lock. Эти фиксированные порядки блокировок и есть высшее искусство потокобезопасности. Если все им следуют, deadlock не может возникнуть, если кто-то меняет порядок, deadlock запрограммирован.
Коротко о главном
Три вещи стоит сказать. ISO9660 и CDDA у меня лишь каркасы, они умеют читать (даже не пытайтесь :-) глючная штука ), но не писать, чего для оптических носителей обычно и хватает. TriaFS, это мой собственный формат, простой для моего понимания, ведь каждое решение в дизайне я принял сам, но и читаемый лишь моей системой. А EXT, это самая зрелая из трёх, в то же время самая сложная, и мой драйвер покрывает далеко не всё, что умеют настоящие реализации ext2/3/4. Для моей системы это осознанный баланс - достаточно, чтобы читать настоящие диски, и просто настолько, чтобы ещё видеть ее "насквозь".
Конец серии
На этом дуга замкнута. open("/home/x.txt") из программы путешествует через VDS, становится разделом и путём в VFS, абстрактный слой спрашивает "какая ФС?", конкретная файловая система переводит путь в последовательность блоков, слой разделов пересчитывает их в абсолютные секторы, слой Storage блокирует и вызывает дальше, а IDE или AHCI наконец достают байты с вращающегося или мигающего диска. Каждый слой задаёт ровно один вопрос и передаёт остальное вниз и в этом вся магия многослойной системы.
Это была серия про файловую систему, от VDS до последнего сектора. Когда система растёт дальше, растут и эти слои, настоящий путь блочного устройства через VDS из самой первой части, например, всё ещё ждёт, чтобы его достроили. Но это другая история, для другого дня, для другой статьи.
Было бы интересно увидеть ваши комментарии и улучшить статьи.
◀ Предыдущая статья Содержание Следующая статья ▶
*Система не стоит на месте, поэтому в дальнейшем тексты могут не совпадать с реальным положением