Linux Kernel Guru

вопрос не про VFS и даже не про кернел. если, конечно,
я его правильно понял.

> Вот здесь не понятно:
> if (inode->i_ino != ino)
>         continue;

это же hash, возможны коллизии.

ФОРМАТИРУЙТЕ КОД.

О... inode cache...
"И Ленин такой молодой и юный октябрь впереди!" :)

Предчувствую, что следующим вопросом будет, зачем нужны iget4 и iget5.
Книжку посоветовать что ли...

Конечно посоветуй.

Я так и не получил ответа на вопрос:
Я правильно понимаю:

1)inode_hashtable - это голова двухсвязного списка всех голов индексных дескрипторов в системе!


2)Этой строчкой получаем голову двухсвязного списка файловой системы на которую указывает sb и на которой "расположен" ino:
struct list_head * head = inode_hashtable + hash(sb,ino);

> Я так и не получил ответа на вопрос:

получили, вообще-то :)

> Этой строчкой получаем голову двухсвязного списка файловой системы на которую указывает sb
> и на которой "расположен" ino:

на которой расположены _все_ inode's у которых
hash(sb,ino) совпадает.

>Конечно посоветуй.

Наобещал, а мои книжки по VFS морально устарели. Посыпаю голову пеплом. :(

В общем, идея примерно такая. Inode cache - вещь довольно странная по сути. Как правило у VFS есть кэш открытых файлов на уровне dentry cache (грубо говоря, кэш: имя->incore inode). При открытии уже открытого файла он достается из dentry cache. По большому счету inode cache может непосредственно пригодиться только в том случае, когда открывается тот же файл, но через другое имя(например, hard link). Inode cache, как и само понятие inode - внутренняя вещь для файловой системы и его позиционирование на уровне VFS обязательно вызывает ряд проблем с тем, что VFS навязывает свой интерфейс файловой системе(очевидно, dentry cache, как понятие корректное, такой проблемы не имеет). Проявляться это может в том, что файловая система реализует inode, но, например, разрядность номеров выше, чем в VFS; другая проблема может проявляться в том, что файловая система реализует inode, но в ней живут разные "файлы"; третий вариант возникает, когда файловая система вообще не реализует inode и понятие VFS inode очень плохо накладывается на эту файловую систему даже во втором-третьем приближении.

Решение возникающих проблем было возможно двумя путями:
1) отказаться от VFS inode cache и дать ФС реализовать внутренний кэш по-своему,
2) попытаться модернизировать VFS inode cache, чтобы он соответствовал насущным реалиям.

В Linux пошли по второму пути. Поскольку единственным потенциальным пользователем inode cache файлов данной файловой системы является эта файловая система, она сама реализует поиск в inode cache, но не полностью, а через helper. Интерфейсы iget4/iget5 как раз реализуют такой поиск: им передается сам helper и blob, они ищут в кэше используя свои внутренние соображения (по хэшу, сверяя sb и i_ino), но при совпадении не возвращуют найденную inode, а предварительно вызывают helper, передав ему найденную inode и blob. Helper уже определяет окончательно в соответствии с blob, нужная ли inode найдена, если нет, то поиск продолжается. В простейшем случае это может использоваться для номеров inode с большим числом разрядом. В этом случае blob может быть указателем на большое число u64* или u128*, которое представляет реальный номер inode, а helper может по дополнительным полям inode(проинициализированным файловой системой при открытии) определять, нужная ли это inode.

Ага, Murr опять набросился на inode cache :)

этак ты его совсем запутаешь, это ты уже про int(*test)()
helper, он-то спрашивает, почему ->i_ino == ino проверяется
еще раз.

idle:

Это чтобы жизнь раем на казалась. :)