From: Dominik Kubla <dominik@kubla.de>
To: Horst von Brand <vonbrand@inf.utfsm.cl>
Cc: Kasper Dupont <kasperd@daimi.au.dk>, Miles Bader <miles@gnu.org>,
DervishD <raul@pleyades.net>,
Linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: About /etc/mtab and /proc/mounts
Date: Thu, 27 Feb 2003 17:40:03 +0100 [thread overview]
Message-ID: <200302271740.06139.dominik@kubla.de> (raw)
In-Reply-To: <200302271600.h1RG0Cdh011948@eeyore.valparaiso.cl>
On Thursday 27 February 2003 17:00, Horst von Brand wrote:
> Dominik Kubla <dominik@kubla.de> said:
> > Quoting the Solaris 8 man page:
>
> I fail to see any significant difference to /proc/mounts (possibly
> expanded). Sure, /proc is the wrong place for this kind of stuff, but...
Then i suggest that you re-read the mnttab(4) man page and compare
it to the Linux implementation. :-)
Keep in mind that i only qouted some parts of the man page. Some thing
are just details (but as we all know details do matter):
[Linux]
# ls -l /proc mounts
lrwxrwxrwx 1 root root 11 Feb 27 17:10 /proc/mounts ->
self/mounts
# ls -l /proc/self/mounts
-r--r--r-- 1 root root 0 Feb 27 17:11 /proc/self/mounts
# wc -c /proc/self/mounts
1058 /proc/self/mounts
[Solaris]
# ls -l /etc/mnttab
r--r--r-- 1 root 1178 Feb 25 16:26 /etc/mnttab
# wc -c /etc/mnttab
1178 /etc/mnttab
The snapshot feature as quoted in the man page is not present under
Linux. The poll(2) feature is not implemented. The solaris mntfs also
implements special ioctrls. Quoting the man page again:
[...]
IOCTLS
The following ioctl(2) calls are supported:
MNTIOC_NMOUNTS
Returns the count of mounted resources in the current
snapshot in the uint32_t pointed to by arg.
MNTIOC_GETDEVLIST
Returns an array of uint32_t's that is twice as long
as the length returned by MNTIOC_NMOUNTS. Each pair of
numbers is the major and minor device number for the
file system at the corresponding line in the current
/etc/mnttab snapshot. arg points to the memory buffer
to receive the device number information.
MNTIOC_SETTAG
Sets a tag word into the options list for a mounted
file system. A tag is a notation that will appear in
the options string of a mounted file system but it is
not recognized or interpreted by the file system code.
arg points to a filled in mnttagdesc structure, as
shown in the following example:
uint_t mtd_major; /* major number for mounted fs */
uint_t mtd_minor; /* minor number for mounted fs */
char *mtd_mntpt; /* mount point of file system */
char *mtd_tag; /* tag to set/clear */
If the tag already exists then it is marked as set but
not re-added. Tags can be at most MAX_MNTOPT_TAG long.
MNTIOC_CLRTAG
Marks a tag in the options list for a mounted file
system as not set. arg points to the same structure as
MNTIOC_SETTAG, which identifies the file system and
tag to be cleared.
[...]
There is also an extended set of library functions to go along with that,
eg. getmntany(3), getextmntent(3), resetmnttab(3) and hasmntopt(3).
It is very helpful that one can get the time a mount happened! You can
not get this kind of information on Linux, neither from /etc/mtab nor from
/proc/self/mounts.
getextmnttab(3) also gives easy access to the device major and minor
number of the mount point.
So there are quite some differences between the Linux proc file and
the Solaris mntfs filesystem. If these differences justify us doing it the
same way is debateable.
The strongest argument i see is: It's already been done this way by one
major Unix version, so why should Linux reinvent the wheel. Again.
Regards,
Dominik
--
"What this country needs is a short, victorious war to stem the tide of
revolution." (V.K. von Plehve, Russian Minister of Interior on the eve of
the Russo-Japanese war.)
next prev parent reply other threads:[~2003-02-27 16:29 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-19 11:21 DervishD
2003-02-26 9:18 ` Kasper Dupont
2003-02-26 10:26 ` Miquel van Smoorenburg
2003-02-26 11:00 ` Olaf Dietsche
2003-02-26 11:14 ` Måns Rullgård
2003-02-26 11:44 ` Kasper Dupont
2003-02-26 12:16 ` Olaf Dietsche
2003-02-26 12:34 ` Måns Rullgård
2003-02-26 13:39 ` Olaf Dietsche
2003-02-26 13:54 ` Måns Rullgård
2003-02-26 14:23 ` Olaf Dietsche
2003-02-27 4:14 ` Miles Bader
2003-02-27 6:40 ` Kasper Dupont
2003-02-27 7:03 ` Joseph Wenninger
2003-02-27 8:28 ` Kasper Dupont
2003-03-05 0:03 ` Jamie Lokier
2003-02-27 7:06 ` Miles Bader
2003-02-27 8:25 ` Kasper Dupont
2003-02-27 8:42 ` Miles Bader
2003-02-27 9:21 ` jw schultz
2003-02-27 9:49 ` Miles Bader
2003-02-27 23:33 ` Kasper Dupont
2003-02-27 12:48 ` Denis Vlasenko
2003-02-27 23:28 ` Kasper Dupont
2003-02-28 6:15 ` Denis Vlasenko
2003-03-02 13:04 ` DervishD
2003-03-02 14:16 ` Kasper Dupont
2003-03-03 1:04 ` jw schultz
2003-03-03 12:22 ` Kasper Dupont
2003-03-04 2:02 ` jw schultz
2003-03-05 12:57 ` Kasper Dupont
2003-03-06 1:18 ` jw schultz
2003-03-06 23:30 ` Kasper Dupont
2003-03-04 11:16 ` DervishD
2003-03-04 11:08 ` DervishD
2003-02-27 9:46 ` Kasper Dupont
2003-02-27 9:58 ` Miles Bader
2003-02-27 12:26 ` Gabriel Paubert
2003-02-27 7:07 ` Joseph Wenninger
2003-02-27 7:08 ` Dominik Kubla
2003-02-27 8:12 ` Kasper Dupont
2003-02-27 9:11 ` Dominik Kubla
2003-02-27 16:00 ` Horst von Brand
2003-02-27 16:31 ` Christoph Hellwig
2003-02-27 16:40 ` Dominik Kubla [this message]
2003-02-27 19:47 ` Kasper Dupont
2003-02-27 22:13 ` Valdis.Kletnieks
2003-02-27 22:31 ` Kasper Dupont
2003-02-27 23:54 ` Miquel van Smoorenburg
2003-02-28 1:37 ` Miles Bader
2003-03-02 12:53 ` DervishD
2003-03-02 14:00 ` Kasper Dupont
2003-03-04 11:02 ` DervishD
2003-03-04 12:09 ` Kasper Dupont
2003-03-04 14:53 ` DervishD
2003-03-02 12:51 ` DervishD
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200302271740.06139.dominik@kubla.de \
--to=dominik@kubla.de \
--cc=kasperd@daimi.au.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=miles@gnu.org \
--cc=raul@pleyades.net \
--cc=vonbrand@inf.utfsm.cl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®