Подскажите по типам драйверов и расположении в иерархии.

[exploys]

Подскажите по типам драйверов и расположении в иерархии.
Интересует Windows. В будущем Linux.
Делаю RAM диск с сжатием. Отведенное ОЗУ фиксировано, а объем устройства плавает в зависимости от

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

это Kernel mode drivers (драйверы режима ядра) -> уровень промежуточный (intermediate) драйвера

виртуальных дисков.
Возникает несколько вопросов:
1. Как быть с динамически меняющимся размером блоков или их количеством в зависимости от сжатия?
2. Какой тип драйвера имеет доступ и управление к таблице занятых кластеров/блоков?
3. Какой тип драйвера имеет доступ и управление к таблице бэд секторов и какие виды секторов помимо

bad и good бывают?

Правильно ли я представляю себе иерархию драйверов?

Драйвер файловой системы (Kernel mode drivers (high-level))
  ^ |
  |  V
Буферный кэш-пул
  ^ |
  |  V
Драйвер логического диска (виртуального) (Kernel mode drivers (intermediate-level))
  ^ |
  |  V
Драйвер физического диска (устройства) (Kernel mode drivers (low-level))
  ^ |
  |  V
Физический диск (устройство)

[Ochkarik]

не совсем понял, какая связь между драйвером виртуального диском и бэд-секторами?
вы собираетесь ошибки диска эмулировать?)
или вам вплоть до физического уровня надо ВСЕ сделать?

может быть в качестве учебного примера вам подойдет RamDisk и ряд вопросов снимется?)

архитектура - вроде похоже на правду. хотя насчет кэша не уверен... вы какой кэш имели в виду?
чуть подробнее наверное можно попробовать поискать тут:
Storage Driver Architecture или на примере PCI IDE Controller  целиком стек.
и в разделе Installable File System

[exploys]

Так ну ща попробуем с RamDisk-ом

Бэд блоки чисто для понимания.
Буферный пул имеется ввиду - кэш ОС.
И самое интересное если я сделаю такой же RAM но с сжатием то как поведёт себя файловая система изза того что размер диска то увеличивается то уменьшается?

Добавлено через 12 минут и 25 секунд:
На счет того, что DDK надо использовать, а в частности WDF (Kernel Mode Driver Framework (KMDF) для вирт диска и User Mode Driver Framework (UMDF) если для ФС) знаю.
Просто есть неясные момент.

[Ochkarik]

не буду врать, я дисками я никогда особо не разбирался, но:
1. диспечер кеша (судя по тому, что его функции  CcXXX оперируют с объектами PFILE_OBJECT) должен находится где то над файловой системой либо рядом.
2. а кроме того, функции кеширования описаны в разделе  IFS. так что опять же...

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

[exploys]

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

[Ochkarik]

с линуксом, увы, помочь не могу)

[RXL]

exploys, логично, что драйвер конкретной ФС должен быть под драйвером VFS и над кешом.

Тут Linux Device Drivers третьей редакции:
https://club.shelek.ru/viewfiles.php?id=32

По части ФС:
http://inglorion.net/documents/tutorials/tutorfs/
http://www.ibm.com/developerworks/linux/library/l-linux-filesystem/

[Ochkarik]

RXL, видимо в линуксе кэшируются дисковые блоки, а в Windows - файлы. вот так нелогично у них получилось)
но плюсы/минусы наверное есть в обоих подходах...

[RXL]

Блоки - это логично. Файлы - не логично. Потому, что файлы состоят из блоков, но не все блоки нужно кешировать. Думаю в NT как раз блоки файлов кешируются, а не файлы целиком.

[Ochkarik]

Ром, ну речь же не о том что файлы состоят из байт и килобайт)

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

[RXL]

А... Понятно.

В Линуксе (и во многих других unix-like) также можно читать устройства и содержимое файлов в обход кеша - direct IO.

[Ochkarik]

да и в Windows - можно.
 думаю что по функционалу современные ОСи мало чем отличаются)

[RXL]

К примеру, в последней статье Макс писал, что у HP-UX нет direct IO. Значит не все. Архитектуры все таки разные.

[Ochkarik]

однако люди пишут что можно включить... правда разом для всего раздела. 
To enable direct IO on HPUX you need to set certain vxvfs mount
options: mincache=direct covosync=direct.
только... надо ли это?
но это уже оффтопик)
и тем более в этом я вообще не-в-зуб-ногой)

[exploys]

Ром, ну речь же не о том что файлы состоят из байт и килобайт)

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

Тут видимо дело в том, что в Windows предполагается использовать одну файловую систему, а в Linux множество под VFS, в том числе через FUSE.
По этому если давать каждой ФС буферный пул, может получиться ненужная множественная повторная буферизация.
Если же буферный пул давать VFS, то это может быть не оптимально для файловых систем со сжатием. Лучше хранить в ОЗУ сжатые блоки, чем распакованные куски файлов. Тем более это нужно делать если ФС с шифрованием, держать шифрованные никаких проблем, а расшифрованные в памяти не есть гуд.

Кстати, а кто-нибудь делал и насколько легко реализуется собственная ФС под Windows?
Я так понимаю легкого механизма типа FUSE там нету, есть только виртуальный слой "устанавливаемой файловой системы" (Installable File System) и нужно использовать WDK Драйвер файловой системы (Kernel mode drivers (high-level))

Добавлено через 4 минуты и 52 секунды:
И ещё, в файловых системах NTFS, ext2/3, XFS, ZFS файлы всегда хранятся последовательным набором блоков на диске или односвязным списком блоков (один файл может быть фрагментирован) и где тогда хранятся метаданные о последовательности блоков, в конце каждого из этих блоков?

[Finch]

exploys, NTFS закрытый стандарт, но документацию по нему найти можно. Но она вся написана путем обратного инжеринга.
Другие озвученные тобой файловые системы это отерытый стандарт. Можеш спокойно по ним найти официальные доки.
Вот например по ext2 http://www.opennet.ru/docs/RUS/ext2fs_lowlevel/

[RXL]

О Ext2/3 сказать могу: там тройная система. В самом inode хранятся указатели на 15 блоков: 13 для прямой адресации, один для косвенной и один для двойной косвенной. Сперва используется прямая адресация. Далее используется косвенная адресация через блок, хранящий указатели на блоки с данными. Потом вступает в действие двухуровневая косвенность: inode ссылается на блок, содержащий ссылки на другие блоки, которые, в свою очередь, ссылаются на блоки с данными. В Ext4 выделение несколько переделали - реализовали экстенты для более производительного управления.

[exploys]

Кстати, а кто-нибудь сам писал собственные файловые системы или устанавливал другие файловые системы под Windows?

[RXL]

Что значит - устанавливал? Использовал? Тогда - да, я использовал ext2/ext3 под Виндой - IFS driver.

[Dimka]

Есть драйверы разных ФС из Linux: для ext2, ext3, Raiser-FS. На XP работали сносно. С тех давних пор на одной машине две операционки на разных дисках не держал.