LINUX.ORG.RU

Linux Kernel Guru


0

0

пожалуйста, если вы не врубаетесь про что речь не засоряйте ветку форума!!! Это отвлекает от толковых ответов!

вопрос по VFS, но подобные методы я встречал и в сетевой подсистеме. Вероятно также можно найти и в других подстистемах!

Я правильно понимаю:

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


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

static inline unsigned long hash(struct super_block *sb, unsigned long i_ino)
{
unsigned long tmp = i_ino + ((unsigned long) sb / L1_CACHE_BYTES);
tmp = tmp + (tmp >> I_HASHBITS);
return tmp & I_HASHMASK;
}


Дело в том, что вышеописаннаю переменнаю head используется функцией find_inode и там есть такой код:

tmp = head;
for (;;) {
tmp = tmp->next;
inode = NULL;
if (tmp == head)
break;
inode = list_entry(tmp, struct inode, i_hash);

Вот здесь не понятно:
---------------------------------

if (inode->i_ino != ino)
continue;
if (inode->i_sb != sb)
continue;
------------------------------------


Если же hash хэширует по sb и inode, то почему тогда здесь идет проверка на то что указатель на суперблок может не соответствовать тому по которому мы выше получмли адрес head?????????



ПЛИЗ - РАЗЪЯСНИТИ СИТУАЦИЮ!
СПАСИБО!!!

anonymous

Re: Linux Kernel Guru

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

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

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

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

idle ★★★★★ ()
Ответ на: Re: Linux Kernel Guru от Murr

Re: Linux Kernel Guru

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

Murr ★★ ()
Ответ на: Re: Linux Kernel Guru от Murr

Re: Linux Kernel Guru

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

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


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

anonymous ()
Ответ на: Re: Linux Kernel Guru от anonymous

Re: Linux Kernel Guru

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

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

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

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

idle ★★★★★ ()
Ответ на: Re: Linux Kernel Guru от mokhout

Re: Linux Kernel Guru

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

Наобещал, а мои книжки по 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 ★★ ()
Ответ на: Re: Linux Kernel Guru от Murr

Re: Linux Kernel Guru

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

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

idle ★★★★★ ()
Ответ на: Re: Linux Kernel Guru от idle

Re: Linux Kernel Guru

idle:

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

Murr ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.