Как получить список Ф.С.

ну считай из /proc/mounts всево делов.

> ну считай из /proc/mounts всево делов.

cat /proc/mounts != mount

/proc/mounts показывает лишь те точки монтирования, которые входят в пространство имен (namespace) текущего процесса. а вот mount показывает все точки монтирования. если у вас в системе несколько пространств имен и в них заданы различные точки монтирования, вывод будет очевидно отличаться.

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

// wbr

ну незахотел чел сырцы mount'а читать, чё делать?

mount показывает то, что сам записал в /etc/mtab (и то не всегда).

Вероятность того, что процесс запустили с NEWNS близка к 0, тем не менее лучше читать именно /etc/mtab, который в инекоторых случаях есть ссылка на /proc/mounts.

getfsstat (2) - get list of all mounted file systems

> getfsstat (2) - get list of all mounted file systems

hm.. а это точно (2)? а например на RHEL4 не нахожу:

$ uname -a
Linux foo 2.6.9-5.ELsmp #1 SMP Wed Jan 5 19:30:39 EST 2005 i686 i686 i386 GNU/Linux
$ grep -r getfsstat /usr/include/*

// wbr

BSD, возвращает struct statfs, странно, что его в линуксе нет

посмотри statfs (2) -- по крайней мере в debian оно есть, может его можно задействовать

> BSD, возвращает struct statfs, странно, что его в линуксе нет

да я ее и в последней NetBSD виду лишь в compat_20 :)

$ man getfsstat
man: no entry for getfsstat in the manual.
$ grep -r getfsstat /usr/include/*
/usr/include/sys/syscall.h:/* syscall: "compat_20_getfsstat" ret: "int" args: "struct statfs12 *" "long" "int" */
/usr/include/sys/syscall.h:#define SYS_compat_20_getfsstat 18
/usr/include/sys/syscallargs.h:struct compat_20_sys_getfsstat_args {
/usr/include/sys/syscallargs.h:int compat_20_sys_getfsstat(struct lwp *, void *, register_t *);
$ man statfs
man: no entry for statfs in the manual.
$ uname -a
NetBSD NBSD1 4.99.1 NetBSD 4.99.1 (GENERIC) #0: Tue Sep 12 18:42:35 NOVST 2006 toor@NBSD1:/usr/build/obj/sys/arch/i386/compile/GENERIC i386

> посмотри statfs (2) -- по крайней мере в debian оно есть, может его можно задействовать

что statfs что statvfs - обе возвращают лишь информацию о файловой системе, которой принадлежит заданный путь и ничего не говорят про существующие точки монтирования so видимо не поможет.

ps: да cat /proc/mounts и хрен с ним.

// wbr

cat /proc/filesystems

getmntent(3) на /etc/mtab

> /proc/mounts показывает лишь те точки монтирования, которые входят в пространство имен (namespace) текущего процесса. а вот mount показывает все точки монтирования.

А ты сам пробовал? Если да, то ты нашел серьезный баг. Процесс в отдельном namespace, IIRC, не может видеть других namespace'ов и mount'ов - никак, даже с exec("mount").

> А ты сам пробовал?

да, по долгу службы пришлось бо это важная особенность системы.

> Если да, то ты нашел серьезный баг. Процесс в отдельном namespace, IIRC, не может видеть других namespace'ов и mount'ов - никак, даже с exec("mount").

но тем не менее видит :) проверялось на RHEL4/i386 штатное ядро aka Linux foo 2.6.9-5.ELsmp #1 SMP Wed Jan 5 19:30:39 EST 2005 i686 i686 i386 GNU/Linux.

проверить кстати оч просто: создаете два дочерних процесса через clone с CLONE_NEWFS, и после в одном из них делаете какие-то маунты и смотрите их в контексте этого процесса через /proc/mounts [у меня он например слинкован на self/mounts что вполне логично].

дык вот, оба процесса видят лишь свои личные маунты что ожиждаемо. а вот root, который работает параллельно в оригинальном пространстве имен, через mount видит точки монтирования и свои и чужие [все новые в дочерних процессах]. даже в принципе забавнее - если дочерние процессы сами не размонтируют созданные ими маунты, то по выходу процесса они никуда не деваются бо namespace is busy хотя никто из процессов к нему уже не подключен. висящие короче пространства с маунтами в никуда. и root может их спокойно размонтировать через блочное устройство a'la "# umount /dev/hdXY" хотя реально эти точки монтирования находятся вне его пространства.

// wbr

Исходя из этого

> дык вот, оба процесса видят лишь свои личные маунты что ожиждаемо.

> root, который работает параллельно в оригинальном пространстве имен, через mount видит точки монтирования и свои и чужие

ну так у родительского процесса пространство имен включает в себя и дочерние, так что mount таки не пресекает границ namespace'ов. Нет?

> ну так у родительского процесса пространство имен включает в себя и дочерние, так что mount таки не пресекает границ namespace'ов. Нет?

нееее, дочерний процесс, созданный через clone(2) с флагом CLONE_NEWNS получает свое собственное пространство имен, которое при создании является точной копией пространства родителя. и все дальнейшие маунты или анмаунты, сделанные дочерним процессом, отражаются лишь в его личной копии, но никак не влияют на пространство родителя.

--- man clone ---
CLONE_NEWNS
(Linux 2.4.19 onwards) Start the child in a new amespace.

Every process lives in a namespace. The namespace of a process is the data (the set of mounts) describing the file hierarchy as seen by that process. After a fork(2) or clone(2) where the CLONE_NEWNS flag is not set, the child lives in the same namespace as the parent. The system calls mount(2) and umount(2) change the namespace of the calling process, and hence affect all processes that live in the same namespace, but do not affect processes in a different namespace.

After a clone(2) where the CLONE_NEWNS flag is set, the cloned child is started in a new namespace, initialized with a copy of the namespace of the parent.

Only a privileged process may specify the CLONE_NEWNS flag. It is not permitted to specify both CLONE_NEWNS and CLONE_FS in the same clone call.
--- man clone ---

// wbr