OSDev

Драйвер ФС может использовать файлы ссылок .lnk как в Windows. В любом случае, если ФС поддерживает ссылки, то это и есть точно такой же файл, только скрытый от пользователя, другого не дано.

Это уже функции VFS.

ФС делится на 2 аспекта: формат разметки, и драйвер ФС. Любая ФС умеет только одно - хранить кластеры, и больше ничего. FAT это обеспечивает. Всё остальное делает драйвер ФС. Не важно, как драйвер называется - надстройкой или просто драйвер, суть драйвера от этого не меняется.
Лучше использовать более менее распространёный формат разметки, не обязательно FAT, хоть EXT, хоть NTFS, а на уровне своего драйвера ФС реализовать все функции, которые нужны системе.

Не любая. Например, журналируемые ФС (ext3, ext4, NTFS, ...) держут у себя журнал...

ФС хранит файлы, а не класторы.
А кто мешает добавить журнолирование в FAT ? - Никто.
Также и в журналируемые ФС (ext3, ext4, NTFS, ...) держат они журнал ну всеравно - это фактически очень специализированный файл.

vkos, ты думаешь, что на FAT нельзя реализовать журналирование? Завести специальный файл и писать в него тоже самое, что пишет драйвер EXT3 закон не запрещает :) Я просто хотел сказать, что многие фичи на самом деле можно реализовать поверх существующих ФС, если подойти творчески. Любая ФС = FAT + x + y + новое название :)

vkos

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

Можно реализовать полноценный UNIX не только на FAT, но и на плоской файловой системе, начисто лишённой каталогов вообще (когда все файлы свалены в одну кучу) -- и система будет нормально работать. Файловая система никак не влияет на поддержку процессов и потоков, на виртуальную память, на синхронизацию и обмен сообщениями, на драйверы "железа" и т.п. Более того, ядро вполне может использовать свою иерархию объектов (отдельные "каталоги" для драйверов, процессов, потоков, файлов и т.п.) -- это его сугубо личное дело, не имеющее никакого отношения к файловой системе. Но, естественно, ядро не сможет за файловую систему реализовать иерархию для файлов, хранящихся на диске с такой ФС -- с точки зрения ядра (и пользователя) все эти файлы будут находиться в одном каталоге внутри имерархии каталогов операционной системы. Однако замена файловой системы на поддерживающую иерархическую структуру каталогов сразу даёт пользователю иерархическую организацию файлов на диске без необходимости внесения каких-либо изменений в ядро системы.

Так что ФС не накладывает ограничений на функциональные возможности ядра: она накладывает ограничения на то, какие возможности будут доступны на носителе, использующем эту ФС.

Кстати, ничто не мешает иметь в одной ОС (с одним и тем же ядром) несколько файловых систем -- собственно, и линух, и вындовз такими системами и являются. А можно сделать ОС и вовсе без файловых систем (в них не нуждаются, например, системы, управляющие простыми встраиваемыми контроллерами, у которых отсутствуют диски; ядро ОС и выполняемые им программы в этом случае располагается в ПЗУ). Естественно, если у оси нет файловых систем, то и файловые операции окажутся невозможными.

Chizh



Вообще-то файловая система -- это способ логической организации хранимой на устройстве (обычно диске) информации. Можно провести аналогию с языками высокого уровня. Например, в Си очень часто используются структуры -- они как раз объединяют байты памяти в некоторую логически связанную структуру (прошу прощения за тавтологию). На низком уровне структура всё равно остаётся кучей байтов, но программист-то уже имеет дело с куда более удобными вещами -- полями структуры, и ему не надо задумываться о всяких там базовых адресах, смещениях, выравниваниях и т.п. Точно то же самое имеет место и на дисках: файловая система лишь скрывает от программиста низкоуровневые особенности хранения информации и предоставляет более удобные в использовании логические абстракции (каталоги, файлы, права доступа и т.п.).

Кстати, ФС не обязана распределять место кластерами ;) Например, файловая система на старых мэйнфреймовских дисках IBM распределяла место так называемыми экстентами, причём один экстент занимал целое число дорожек или цилиндров, однако его размер мог отличаться от файла к файлу. Когда экстент оказывался полностью занятым, файлу выдавался дополнительный экстент. Кстати сказать, дорожка диска там не делилась на блоки фиксированного размера: блоки могли иметь произвольную длину в пределах ёмкости дорожки, поэтому у каждого файла было не только имя, но ещё и размер физического блока, а для многих файлов -- ещё и размер логической записи. Кстати, были не только физические блоки, но и логические, имевшие ёмкость в пределах одного цилиндра (а в цилиндре могло быть несколько десятков дорожек). В общем, файловая система может быть устроена по-разному в зависимости от целей разработчика и возможностей аппаратуры :)

насчёт ограничения -- есть ядро, есть модули, модули - это объекты, относятся к какимто классам. На диске должны быть сохранены методы этих классов и конкретные экземпляры объектов (со своими данными), связанные между собой в паутину. ни одна существующая фс изначально такой подход не поддерживает, а значит, ты не сможешь реализовать такой способ хранения ядра и модулей, это и есть ограничение. ;)

Dragon

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

На мой взгляд, ФС влияет только на безопасность системы (а именно, ACL). Ведь в FAT ACL может менять кто хочет, и это приводит к бессмысленности ACL (например, бит "только для чтения"). С другой стороны, такие ACL, как в WinNT - это наоборот беспредел. С точки зрения сисадмина. Допустим, он воткнул винт с NTFS в другой комп. Админ не имеет права читать каталоги и файлы, которые на этом винте!
Что касается ACL в Linux, то там на порядок проще, но rwx - недостаточно, хотелось бы иметь побольше атрибутов. Например, v (visible) или d (deletable) ну и прочее. Но uid, gid, all - полей достаточно.

Просто у группы "Администраторы" единый GUID. Но если винчестер попадает в чужие руки, то ни какие права доступа вообще не имеют значения, если данные не шифруются.