VFS - как узнать свою точку монтирования из read_super() ?

читать /proc/mounts :) ПС: не уверен, что из ядро можно это сделать, тогда посмотри реализацию /proc :)

> читать /proc/mounts :)

а если у нас 10 различных точек монтирования одной и той же файловой системы foo? как их различить - кто конкретно сейчас моя а кто нет?

да и в любом случае, не факт, что на момент вызова read_super() procfs что-то знает о монтируемой системе. скорее всего, эта информация туда попадает лишь после успешного завершения read_super() [нужно смотреть].

// wbr

> AFAIU в самой структуре super_block этого нет :(

не знаю как насчет 2.4, а в 2.6 в super_blcok
есть
struct dentry *s_root;

возможно это то что нужно.

> не знаю как насчет 2.4, а в 2.6 в super_blcok есть struct dentry *s_root;

это есть, думаю, даже в 2.0 :)

> возможно это то что нужно.

нет, это несколько не то. s_root - это указатель на корневой каталог монтируемой файловой системы i.e. это как раз то, что я должен создать в read_super().

// wbr

>нет, это несколько не то. s_root - это указатель на корневой каталог монтируемой >файловой системы i.e. это как раз то, что я должен создать в read_super().

да конечно, но у dentry есть указатель на parent, у того есть указатель на его parent и так до root

> да конечно, но у dentry есть указатель на parent, у того есть указатель на его parent и так до root

конечно, если не считать одной мелочи: при вызове foo_read_super() поле sb->s_root всегда равно NULL :)

sb->s_root - это та структура, заполнение которой от меня собственно и ждет do_kern_mount() при вызове foo_read_super() и в ней не содержится ссылки на dentry низлежащей точки монтирования бо в 99% случаев для read_super() обычной файловой системы она просто не нужна (сокрытие данных) да и не место ей там by design. а у меня оставшийся 1% случаев :)

// wbr

ps: ессно "выделение и заполнение"

// wbr

ps: судя по коду штатными средствами узнать точку монтирования AFAIU никак so приходится дублировать через опции mount. кривовато конечно, но что делать. думаю, вопрос снят.

// wbr

По моему superblock создается только один раз при первом монтировании.
А монтироватся он может сколько угодно раз.
Таким образом нельзя соотнести точку монтирования с superblock-ом, т.к. точек монтирования может быть много, а superblock один.

>да конечно, но у dentry есть указатель на parent, у того есть указатель на его parent и так до root

У корневой dentry для файловой системы parent указывает сам на себя.

> У корневой dentry для файловой системы parent указывает сам на себя.

это да, но лишь после того, как я [файловая система] сделаю это явным образом сам в read_super() :)

// wbr

> По моему superblock создается только один раз при первом монтировании. А монтироватся он может сколько угодно раз.

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

в одном экземпляре для каждой файловой системы заводится структура file_system_type в которой содержится название файловой системы a'la "ext2" для вызова mount -t <name> и ссылка на ключевую ф-ю read_super().

> Таким образом нельзя соотнести точку монтирования с superblock-ом, т.к. точек монтирования может быть много, а superblock один.

// wbr

> > По моему superblock создается только один раз при первом
> > монтировании. А монтироватся он может сколько угодно раз.
>
> нет, структура super_block выделяется под каждую точку монтирования
> своя.

хм. вообще-то я про vfs забыл больше, чем знал, но
это мне кажется неверным. sb должен быть один.

ok, смотрим get_sb_bdev()->sget(test_bdev_super).
он ведь вернет 'old' если ->s_bdev совпадает?

> s_bdev - указатель на описание блочного устройства с которым
> мы работаем - а оно для различных точек монтирования очевидно
> будет различным.

?

Под файловой системой в данном случае понимается конкретный экземпляр файловой системы, а не ее тип описываемый структурой file_system_type.

Для каждого экземпляра файловой системы создается всего один superblock.
Т.е. при каждом монтировании не создается нового superblock-а.
superblock создается только при первом монтировании данного экземпляра.
А при последующих монитрованиях используется уже созданный superblock.

> Для каждого экземпляра файловой системы создается всего один superblock. Т.е. при каждом монтировании не создается нового superblock-а. superblock создается только при первом монтировании данного экземпляра. А при последующих монитрованиях используется уже созданный superblock.

обратный вызов struct super_block *read_super(struct super_block *sb, void *data, int silent) для одной и той же файловой системы при втором/третьем/etc вызове получает новый указатель sb. tested :)

AFAIR *можно* переиспользовать уже выделенный ранее super_block, что-то на эту тему я видел давеча в 2.4.x, но есть вариации.

исходников ядра дома нет и проверить не могу -> точный ответ смогу дать только в понедельник [если конечно интересно]. хотя do_kernel_mount() [или kern?] дюже простой как три рубля и истинное положение дел IMHO выявляется за 10 минут.

// wbr

> хм. вообще-то я про vfs забыл больше, чем знал, но
это мне кажется неверным. sb должен быть один.

нет, все-таки это не всегда так :) прокомментировать по коду сейчас не могу за его отсутствием.

> s_bdev - указатель на описание блочного устройства с которым
> мы работаем - а оно для различных точек монтирования очевидно
> будет различным.
> ?

вспомнил. если процитировать "Understanding the Linux Kernel 2d ed", то:

---cut---
do_kern_mount() does:

[snip]

3. Searches the list of superblock objects; if a superblock relative to the block device is already present, returns its address. This means that the filesystem is already mounted and will be mounted again.

4. Otherwise, allocates a new superblock object, initializes its s_dev, s_bdev, s_flags, and s_type fields, and inserts it into the global lists of superblocks and the superblock list of the filesystem type descriptor.

5. Acquires the s_lock spin lock of the superblock.

6. Invokes the read_super method of the filesystem type to access the superblock information on disk and fill the other fields of the new superblock object.
---cut---

в моем случае блочного устройства нет (это фиктивная fs) -> видимо каждый раз создается новая структура sb.

а вообще да, белый челове конечно просканировал бы vfsmntlist, но вот проблема: я отнюдь не уверен, что в момент вызова read_super() там уже есть соотв. запись [скорее всего нет, так как процесс монтирования еще не завершен].

// wbr

> в моем случае блочного устройства нет (это фиктивная fs)

ага, с этого надо было начинать ... тогда у вас нет
FS_REQUIRES_DEV ...

> видимо каждый раз создается новая структура sb.

все в ваших руках: контролируется FS_SINGLE

впрочем, могу и соврать. давно не заглядывал в код 2.4

>> в моем случае блочного устройства нет (это фиктивная fs)
> ага, с этого надо было начинать ... тогда у вас нет
FS_REQUIRES_DEV ...
>> видимо каждый раз создается новая структура sb.
> все в ваших руках: контролируется FS_SINGLE

нет, тут несколько другая ситуация - виртуальная fs (-> != FS_REQUIRES_DEV) должна иметь возможность монтироваться более чем в одну точку (-> != FS-SINGLE). нечто a'la trace fs (-> нужно знать, кого именно собственно трассировать).

> впрочем, могу и соврать. давно не заглядывал в код 2.4

на этом уровне я почти не заметил различий между 2.4 и 2.6. скорее, почти полное заимствование. хотя может и не особо всматривался бо 2.6 пока не интересует.

// wbr

> должна иметь возможность монтироваться более
> чем в одну точку (-> != FS-SINGLE)

мне кажется вы путаете эти вещи. к примеру, proc fs
имеет FS_SINGLE. это вовсе не означает, что ее нельзя
смонтировать дважды. FS_SINGLE именно и означает один
у нас sb или нет.

смотрите do_kern_mount(). FS_SINGLE выбирает между
get_sb_single() и get_sb_nodev() что в свою очередь
определяет параметр compare для get_anon_super().

так что не знаю, что там в LDD написано, но код
не врет :)

> FS_SINGLE именно и означает один у нас sb или нет.

на всякий случай:

это - в сущности - означает, должны ли мы видеть одно
и тоже в разных mountpoints.

примеры:

        proc - да, система-то одна, поэтому FS_SINGLE.

        shm/tmpfs - нет, mountpoint'ы не должны вообще
        никак зависеть друг от друга, => !FS_SINGLE

> мне кажется вы путаете эти вещи. к примеру, proc fs
имеет FS_SINGLE. это вовсе не означает, что ее нельзя
смонтировать дважды. FS_SINGLE именно и означает один
у нас sb или нет.

hm, нужно будет посмотреть повнимательнее в код. охотно верю, что так они и есть бо вывод о единственной точки монтирования proc fs меня то-же несколько смутил [с какой стати собственно?], но небыло времени детально в этом разбираться.

> так что не знаю, что там в LDD написано, но код
не врет :)

AFAIR в LDD по поводу VFS почти ничего не написано. не барское это видимо дело - клепать FS драйверописателям :)

// wbr