* Using /proc/mounts in mountlist.c for linux
@ 2011-04-05 12:36 Philipp Thomas
2011-04-05 14:18 ` Pádraig Brady
2011-05-31 0:14 ` James Youngman
0 siblings, 2 replies; 11+ messages in thread
From: Philipp Thomas @ 2011-04-05 12:36 UTC (permalink / raw
To: bug-gnulib
[-- Attachment #1: Type: text/plain, Size: 443 bytes --]
GNU find will not recognize file systems of type autofs on newer Linux
kernels as autofs entries are only listed in /proc/mounts and mountlist.c
includes glibc mntent.h which takes the _PATH_MOUNTED from paths.h and that
is /etc/mtab.
After a longer discussion, we (SUSE) chose to patch mountlist.c in findutils
to use proc/mounts instead of /etc/mtab which fixed ou problem.
Would gnulib accept the attached patch to mountlist.c?
Philipp
[-- Attachment #2: findutils-use_proc_mounts.patch --]
[-- Type: text/x-patch, Size: 427 bytes --]
Index: gnulib/lib/mountlist.c
===================================================================
--- gnulib/lib/mountlist.c.orig 2007-12-02 12:57:51.000000000 +0100
+++ gnulib/lib/mountlist.c 2010-11-17 13:08:32.133380836 +0100
@@ -71,6 +71,11 @@
# endif
#endif
+#if defined __linux__
+# undef MOUNTED
+# define MOUNTED "/proc/mounts"
+#endif
+
#ifdef MOUNTED_GETMNTINFO /* 4.4BSD. */
# include <sys/mount.h>
#endif
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Using /proc/mounts in mountlist.c for linux
2011-04-05 12:36 Using /proc/mounts in mountlist.c for linux Philipp Thomas
@ 2011-04-05 14:18 ` Pádraig Brady
2011-04-06 11:03 ` Karel Zak
2011-05-31 0:14 ` James Youngman
1 sibling, 1 reply; 11+ messages in thread
From: Pádraig Brady @ 2011-04-05 14:18 UTC (permalink / raw
To: Philipp Thomas; +Cc: util-linux, bug-gnulib
On 05/04/11 13:36, Philipp Thomas wrote:
> GNU find will not recognize file systems of type autofs on newer Linux
> kernels as autofs entries are only listed in /proc/mounts and mountlist.c
> includes glibc mntent.h which takes the _PATH_MOUNTED from paths.h and that
> is /etc/mtab.
>
> After a longer discussion, we (SUSE) chose to patch mountlist.c in findutils
> to use proc/mounts instead of /etc/mtab which fixed ou problem.
>
> Would gnulib accept the attached patch to mountlist.c?
Well locally I have symlinked /etc/mtab -> /proc/mounts since:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f84e3f52
So this would not break anything for me.
Also I understand Fedora 15 will symlink /etc/mtab to /proc/mount too.
What about older kernels though?
I'm wondering should suse be considering making the symlink also,
or otherwise keeping /etc/mtab in sync?
It seems a bit like this gnulib change is doing it in the wrong place.
I've cc'd the util-linux guys who know much more about this than me.
cheers,
Pádraig.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Using /proc/mounts in mountlist.c for linux
2011-04-05 14:18 ` Pádraig Brady
@ 2011-04-06 11:03 ` Karel Zak
2011-04-06 11:41 ` Pádraig Brady
0 siblings, 1 reply; 11+ messages in thread
From: Karel Zak @ 2011-04-06 11:03 UTC (permalink / raw
To: Pádraig Brady; +Cc: Philipp Thomas, util-linux, bug-gnulib
On Tue, Apr 05, 2011 at 03:18:02PM +0100, Pádraig Brady wrote:
> On 05/04/11 13:36, Philipp Thomas wrote:
> > GNU find will not recognize file systems of type autofs on newer Linux
> > kernels as autofs entries are only listed in /proc/mounts and mountlist.c
> > includes glibc mntent.h which takes the _PATH_MOUNTED from paths.h and that
> > is /etc/mtab.
> >
> > After a longer discussion, we (SUSE) chose to patch mountlist.c in findutils
> > to use proc/mounts instead of /etc/mtab which fixed ou problem.
> >
> > Would gnulib accept the attached patch to mountlist.c?
>
> Well locally I have symlinked /etc/mtab -> /proc/mounts since:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f84e3f52
> So this would not break anything for me.
>
> Also I understand Fedora 15 will symlink /etc/mtab to /proc/mount too.
>
> What about older kernels though?
If the find(1) command does not depend on mtab specific features
(e.g. user= mount option) then my suggestion is to use /proc/mounts
everywhere independently on the kernel version.
I guess that mount options are completely irrelevant for find(1),
right? So, /proc/mounts is the right choice.
> I'm wondering should suse be considering making the symlink also,
> or otherwise keeping /etc/mtab in sync?
The mtab file is evil. The goal is to replace the file with the
symlink in the near future. It's already supported (but not enabled
by default) by mount(8) from util-linux v2.19.
We also need a special support for the symlink in mount.nfs and
pam_mount. I hope all these issues will be resolved in the near
future too.
The symlinks is also already required by systemd, and if I good
remember then people from almost all mainstream distributions
collaborate on systemd development, so Fedora-15 is the first, but
not last distro without mtab...
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Using /proc/mounts in mountlist.c for linux
2011-04-06 11:03 ` Karel Zak
@ 2011-04-06 11:41 ` Pádraig Brady
0 siblings, 0 replies; 11+ messages in thread
From: Pádraig Brady @ 2011-04-06 11:41 UTC (permalink / raw
To: Karel Zak; +Cc: Philipp Thomas, util-linux, bug-gnulib
On 06/04/11 12:03, Karel Zak wrote:
> On Tue, Apr 05, 2011 at 03:18:02PM +0100, Pádraig Brady wrote:
>> On 05/04/11 13:36, Philipp Thomas wrote:
>>> GNU find will not recognize file systems of type autofs on newer Linux
>>> kernels as autofs entries are only listed in /proc/mounts and mountlist.c
>>> includes glibc mntent.h which takes the _PATH_MOUNTED from paths.h and that
>>> is /etc/mtab.
>>>
>>> After a longer discussion, we (SUSE) chose to patch mountlist.c in findutils
>>> to use proc/mounts instead of /etc/mtab which fixed ou problem.
>>>
>>> Would gnulib accept the attached patch to mountlist.c?
>>
>> Well locally I have symlinked /etc/mtab -> /proc/mounts since:
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f84e3f52
>> So this would not break anything for me.
>>
>> Also I understand Fedora 15 will symlink /etc/mtab to /proc/mount too.
>>
>> What about older kernels though?
>
> If the find(1) command does not depend on mtab specific features
> (e.g. user= mount option) then my suggestion is to use /proc/mounts
> everywhere independently on the kernel version.
>
> I guess that mount options are completely irrelevant for find(1),
> right? So, /proc/mounts is the right choice.
OK from coreutils' point of view, /proc/mounts is better too.
So +1 from me.
cheers,
Pádraig.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Using /proc/mounts in mountlist.c for linux
2011-04-05 12:36 Using /proc/mounts in mountlist.c for linux Philipp Thomas
2011-04-05 14:18 ` Pádraig Brady
@ 2011-05-31 0:14 ` James Youngman
2011-05-31 2:21 ` Paul Eggert
2011-05-31 9:31 ` Pádraig Brady
1 sibling, 2 replies; 11+ messages in thread
From: James Youngman @ 2011-05-31 0:14 UTC (permalink / raw
To: Philipp Thomas; +Cc: bug-gnulib
On Tue, Apr 5, 2011 at 1:36 PM, Philipp Thomas <pth@suse.de> wrote:
> GNU find will not recognize file systems of type autofs on newer Linux
> kernels as autofs entries are only listed in /proc/mounts and mountlist.c
> includes glibc mntent.h which takes the _PATH_MOUNTED from paths.h and that
> is /etc/mtab.
>
> After a longer discussion, we (SUSE) chose to patch mountlist.c in findutils
> to use proc/mounts instead of /etc/mtab which fixed ou problem.
>
> Would gnulib accept the attached patch to mountlist.c?
I don't know if this patch was accepted, but it shouldn't be. The
problem is that /proc/mounts has incomplete data for /. This will
break gnulib's mountlist, at least with the current form of the patch,
because mountlist will have an incorrect idea of the type of the root
filesystem. Here's an example showing the problem:
~$ cat tryit.sh
#! /bin/sh
f() {
echo "$1"
( ls -l /etc/mtab; find / -maxdepth 0 -printf '%p %F\n' ) |
sed -e 's_^_ _'
}
set -e
cd /etc
f "regular /etc/mtab"
mv mtab mtab.old; ln -s ../proc/mounts mtab
f "with /proc/mounts"
rm mtab; mv mtab.old mtab
~$ sudo sh tryit.sh
regular /etc/mtab
-rw-r--r-- 1 root root 1869 May 30 23:53 /etc/mtab
/ ext3
with /proc/mounts
lrwxrwxrwx 1 root root 14 May 31 01:12 /etc/mtab -> ../proc/mounts
/ rootfs
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Using /proc/mounts in mountlist.c for linux
2011-05-31 0:14 ` James Youngman
@ 2011-05-31 2:21 ` Paul Eggert
2011-05-31 9:31 ` Pádraig Brady
1 sibling, 0 replies; 11+ messages in thread
From: Paul Eggert @ 2011-05-31 2:21 UTC (permalink / raw
To: James Youngman; +Cc: Philipp Thomas, bug-gnulib
On 05/30/11 17:14, James Youngman wrote:
> On Tue, Apr 5, 2011 at 1:36 PM, Philipp Thomas <pth@suse.de> wrote:
>> > Would gnulib accept the attached patch to mountlist.c?
> I don't know if this patch was accepted, but it shouldn't be.
It wasn't; mountlist.c hasn't changed since January.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Using /proc/mounts in mountlist.c for linux
2011-05-31 0:14 ` James Youngman
2011-05-31 2:21 ` Paul Eggert
@ 2011-05-31 9:31 ` Pádraig Brady
2011-05-31 9:42 ` James Youngman
2011-05-31 11:10 ` Karel Zak
1 sibling, 2 replies; 11+ messages in thread
From: Pádraig Brady @ 2011-05-31 9:31 UTC (permalink / raw
To: James Youngman; +Cc: Philipp Thomas, util-linux, bug-gnulib
On 31/05/11 01:14, James Youngman wrote:
> On Tue, Apr 5, 2011 at 1:36 PM, Philipp Thomas <pth@suse.de> wrote:
>> GNU find will not recognize file systems of type autofs on newer Linux
>> kernels as autofs entries are only listed in /proc/mounts and mountlist.c
>> includes glibc mntent.h which takes the _PATH_MOUNTED from paths.h and that
>> is /etc/mtab.
>>
>> After a longer discussion, we (SUSE) chose to patch mountlist.c in findutils
>> to use proc/mounts instead of /etc/mtab which fixed ou problem.
>>
>> Would gnulib accept the attached patch to mountlist.c?
>
> I don't know if this patch was accepted, but it shouldn't be. The
> problem is that /proc/mounts has incomplete data for /. This will
> break gnulib's mountlist, at least with the current form of the patch,
> because mountlist will have an incorrect idea of the type of the root
> filesystem. Here's an example showing the problem:
>
> ~$ cat tryit.sh
> #! /bin/sh
> f() {
> echo "$1"
> ( ls -l /etc/mtab; find / -maxdepth 0 -printf '%p %F\n' ) |
> sed -e 's_^_ _'
> }
>
> set -e
> cd /etc
> f "regular /etc/mtab"
>
> mv mtab mtab.old; ln -s ../proc/mounts mtab
> f "with /proc/mounts"
> rm mtab; mv mtab.old mtab
> ~$ sudo sh tryit.sh
> regular /etc/mtab
> -rw-r--r-- 1 root root 1869 May 30 23:53 /etc/mtab
> / ext3
> with /proc/mounts
> lrwxrwxrwx 1 root root 14 May 31 01:12 /etc/mtab -> ../proc/mounts
> / rootfs
Well I didn't merge it, but for more generic reasons.
It seemed like a bit of a layering violation to me,
and I was unsure that other users of gnulib may need
access to /etc/mtab specific stuff (on older systems).
Here is related output on my Fedora 15 system
which does link /etc/mtab -> /proc/mounts
$ df /
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdb2 13102208 3210896 9758244 25% /
$ df -t rootfs
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 13102208 3210896 9758244 25% /
$ find / -maxdepth 0 -printf "%p %F\n"
/ rootfs
cheers,
Pádraig.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Using /proc/mounts in mountlist.c for linux
2011-05-31 9:31 ` Pádraig Brady
@ 2011-05-31 9:42 ` James Youngman
2011-05-31 11:10 ` Karel Zak
1 sibling, 0 replies; 11+ messages in thread
From: James Youngman @ 2011-05-31 9:42 UTC (permalink / raw
To: Pádraig Brady; +Cc: Philipp Thomas, util-linux, bug-gnulib
2011/5/31 Pádraig Brady <P@draigbrady.com>:
> On 31/05/11 01:14, James Youngman wrote:
>> On Tue, Apr 5, 2011 at 1:36 PM, Philipp Thomas <pth@suse.de> wrote:
>>> GNU find will not recognize file systems of type autofs on newer Linux
>>> kernels as autofs entries are only listed in /proc/mounts and mountlist.c
>>> includes glibc mntent.h which takes the _PATH_MOUNTED from paths.h and that
>>> is /etc/mtab.
>>>
>>> After a longer discussion, we (SUSE) chose to patch mountlist.c in findutils
>>> to use proc/mounts instead of /etc/mtab which fixed ou problem.
>>>
>>> Would gnulib accept the attached patch to mountlist.c?
>>
>> I don't know if this patch was accepted, but it shouldn't be. The
>> problem is that /proc/mounts has incomplete data for /. This will
>> break gnulib's mountlist, at least with the current form of the patch,
>> because mountlist will have an incorrect idea of the type of the root
>> filesystem. Here's an example showing the problem:
>>
>> ~$ cat tryit.sh
>> #! /bin/sh
>> f() {
>> echo "$1"
>> ( ls -l /etc/mtab; find / -maxdepth 0 -printf '%p %F\n' ) |
>> sed -e 's_^_ _'
>> }
>>
>> set -e
>> cd /etc
>> f "regular /etc/mtab"
>>
>> mv mtab mtab.old; ln -s ../proc/mounts mtab
>> f "with /proc/mounts"
>> rm mtab; mv mtab.old mtab
>> ~$ sudo sh tryit.sh
>> regular /etc/mtab
>> -rw-r--r-- 1 root root 1869 May 30 23:53 /etc/mtab
>> / ext3
>> with /proc/mounts
>> lrwxrwxrwx 1 root root 14 May 31 01:12 /etc/mtab -> ../proc/mounts
>> / rootfs
>
> Well I didn't merge it, but for more generic reasons.
> It seemed like a bit of a layering violation to me,
> and I was unsure that other users of gnulib may need
> access to /etc/mtab specific stuff (on older systems).
>
> Here is related output on my Fedora 15 system
> which does link /etc/mtab -> /proc/mounts
>
> $ df /
> Filesystem 1K-blocks Used Available Use% Mounted on
> /dev/sdb2 13102208 3210896 9758244 25% /
> $ df -t rootfs
> Filesystem 1K-blocks Used Available Use% Mounted on
> rootfs 13102208 3210896 9758244 25% /
> $ find / -maxdepth 0 -printf "%p %F\n"
> / rootfs
Thanks for the additional info. I think that would be a bug in
Fedora 15, then.
James.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Using /proc/mounts in mountlist.c for linux
2011-05-31 9:31 ` Pádraig Brady
2011-05-31 9:42 ` James Youngman
@ 2011-05-31 11:10 ` Karel Zak
2011-05-31 23:28 ` James Youngman
1 sibling, 1 reply; 11+ messages in thread
From: Karel Zak @ 2011-05-31 11:10 UTC (permalink / raw
To: Pádraig Brady; +Cc: Philipp Thomas, util-linux, bug-gnulib
On Tue, May 31, 2011 at 10:31:17AM +0100, Pádraig Brady wrote:
> On 31/05/11 01:14, James Youngman wrote:
> > On Tue, Apr 5, 2011 at 1:36 PM, Philipp Thomas <pth@suse.de> wrote:
> >> GNU find will not recognize file systems of type autofs on newer Linux
> >> kernels as autofs entries are only listed in /proc/mounts and mountlist.c
> >> includes glibc mntent.h which takes the _PATH_MOUNTED from paths.h and that
> >> is /etc/mtab.
> >>
> >> After a longer discussion, we (SUSE) chose to patch mountlist.c in findutils
> >> to use proc/mounts instead of /etc/mtab which fixed ou problem.
> >>
> >> Would gnulib accept the attached patch to mountlist.c?
> >
> > I don't know if this patch was accepted, but it shouldn't be. The
> > problem is that /proc/mounts has incomplete data for /. This will
> > break gnulib's mountlist, at least with the current form of the patch,
> > because mountlist will have an incorrect idea of the type of the root
> > filesystem. Here's an example showing the problem:
> >
> > ~$ cat tryit.sh
> > #! /bin/sh
> > f() {
> > echo "$1"
> > ( ls -l /etc/mtab; find / -maxdepth 0 -printf '%p %F\n' ) |
> > sed -e 's_^_ _'
> > }
> >
> > set -e
> > cd /etc
> > f "regular /etc/mtab"
> >
> > mv mtab mtab.old; ln -s ../proc/mounts mtab
> > f "with /proc/mounts"
> > rm mtab; mv mtab.old mtab
> > ~$ sudo sh tryit.sh
> > regular /etc/mtab
> > -rw-r--r-- 1 root root 1869 May 30 23:53 /etc/mtab
> > / ext3
> > with /proc/mounts
> > lrwxrwxrwx 1 root root 14 May 31 01:12 /etc/mtab -> ../proc/mounts
> > / rootfs
That's strange, why for "/" it does not search in the file (mtab) in reverse
order?
example A)
# mount -t ext3 /dev/sda6 /mnt/test
# mount -t ext4 /dev/mapper/kzak-home /mnt/test
... so I have two entries for the same mountpoint:
# grep /mnt/test /proc/mounts
/dev/sda6 /mnt/test ext3 rw,relatime,errors=continue,barrier=0,data=ordered 0 0
/dev/mapper/kzak-home /mnt/test ext4 rw,relatime,barrier=1,data=ordered 0 0
this is correct (ext4 is the second entry):
# find /mnt/test -maxdepth 0 -printf '%p %F\n'
/mnt/test ext4
example B)
the same thing with root FS:
# grep -E '(/dev/sda4|rootfs)' /proc/mounts
rootfs / rootfs rw 0 0
/dev/sda4 / ext3 rw,noatime,errors=continue,user_xattr,acl,barrier=0,data=ordered 0 0
... so I have two entries for the same mountpoint:
# find / -maxdepth 0 -printf '%p %F\n'
/ rootfs
why does it return the first entry? It seems like obvious bug. You
have to read entries in the mtab file in reverse order.
Anyway, /proc/self/mountinfo is definitely more sexy... :-)
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Using /proc/mounts in mountlist.c for linux
2011-05-31 11:10 ` Karel Zak
@ 2011-05-31 23:28 ` James Youngman
2011-06-01 7:56 ` Karel Zak
0 siblings, 1 reply; 11+ messages in thread
From: James Youngman @ 2011-05-31 23:28 UTC (permalink / raw
To: Karel Zak; +Cc: Philipp Thomas, bug-gnulib, util-linux
2011/5/31 Karel Zak <kzak@redhat.com>:
> On Tue, May 31, 2011 at 10:31:17AM +0100, Pádraig Brady wrote:
>> On 31/05/11 01:14, James Youngman wrote:
>> > On Tue, Apr 5, 2011 at 1:36 PM, Philipp Thomas <pth@suse.de> wrote:
>> >> GNU find will not recognize file systems of type autofs on newer Linux
>> >> kernels as autofs entries are only listed in /proc/mounts and mountlist.c
>> >> includes glibc mntent.h which takes the _PATH_MOUNTED from paths.h and that
>> >> is /etc/mtab.
>> >>
>> >> After a longer discussion, we (SUSE) chose to patch mountlist.c in findutils
>> >> to use proc/mounts instead of /etc/mtab which fixed ou problem.
>> >>
>> >> Would gnulib accept the attached patch to mountlist.c?
>> >
>> > I don't know if this patch was accepted, but it shouldn't be. The
>> > problem is that /proc/mounts has incomplete data for /. This will
>> > break gnulib's mountlist, at least with the current form of the patch,
>> > because mountlist will have an incorrect idea of the type of the root
>> > filesystem. Here's an example showing the problem:
>> >
>> > ~$ cat tryit.sh
>> > #! /bin/sh
>> > f() {
>> > echo "$1"
>> > ( ls -l /etc/mtab; find / -maxdepth 0 -printf '%p %F\n' ) |
>> > sed -e 's_^_ _'
>> > }
>> >
>> > set -e
>> > cd /etc
>> > f "regular /etc/mtab"
>> >
>> > mv mtab mtab.old; ln -s ../proc/mounts mtab
>> > f "with /proc/mounts"
>> > rm mtab; mv mtab.old mtab
>> > ~$ sudo sh tryit.sh
>> > regular /etc/mtab
>> > -rw-r--r-- 1 root root 1869 May 30 23:53 /etc/mtab
>> > / ext3
>> > with /proc/mounts
>> > lrwxrwxrwx 1 root root 14 May 31 01:12 /etc/mtab -> ../proc/mounts
>> > / rootfs
>
>
> That's strange, why for "/" it does not search in the file (mtab) in reverse
> order?
>
> example A)
>
> # mount -t ext3 /dev/sda6 /mnt/test
> # mount -t ext4 /dev/mapper/kzak-home /mnt/test
>
> ... so I have two entries for the same mountpoint:
>
> # grep /mnt/test /proc/mounts
> /dev/sda6 /mnt/test ext3 rw,relatime,errors=continue,barrier=0,data=ordered 0 0
> /dev/mapper/kzak-home /mnt/test ext4 rw,relatime,barrier=1,data=ordered 0 0
>
>
> this is correct (ext4 is the second entry):
>
> # find /mnt/test -maxdepth 0 -printf '%p %F\n'
> /mnt/test ext4
>
>
> example B)
>
> the same thing with root FS:
>
> # grep -E '(/dev/sda4|rootfs)' /proc/mounts
> rootfs / rootfs rw 0 0
> /dev/sda4 / ext3 rw,noatime,errors=continue,user_xattr,acl,barrier=0,data=ordered 0 0
>
> ... so I have two entries for the same mountpoint:
>
>
> # find / -maxdepth 0 -printf '%p %F\n'
> / rootfs
>
> why does it return the first entry? It seems like obvious bug. You
> have to read entries in the mtab file in reverse order.
I find this claim most surprising, since getmntent is intended for use
on both /etc/mtab and /etc/fstab and it reads them forwards. As a
system administrator, I would consider it a bug for there to be a
duplicate entry in /etc/mtab, and if as a sysadmin I had actually
somehow put two similar entries into /etc/fstab, I'd expect mount(8)
to use the first match (and mount -a to use all matches).
> Anyway, /proc/self/mountinfo is definitely more sexy... :-)
>
> Karel
>
> --
> Karel Zak <kzak@redhat.com>
> http://karelzak.blogspot.com
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Using /proc/mounts in mountlist.c for linux
2011-05-31 23:28 ` James Youngman
@ 2011-06-01 7:56 ` Karel Zak
0 siblings, 0 replies; 11+ messages in thread
From: Karel Zak @ 2011-06-01 7:56 UTC (permalink / raw
To: James Youngman; +Cc: Philipp Thomas, bug-gnulib, util-linux
On Wed, Jun 01, 2011 at 12:28:46AM +0100, James Youngman wrote:
> 2011/5/31 Karel Zak <kzak@redhat.com>:
> > On Tue, May 31, 2011 at 10:31:17AM +0100, Pádraig Brady wrote:
> >> On 31/05/11 01:14, James Youngman wrote:
> >> > On Tue, Apr 5, 2011 at 1:36 PM, Philipp Thomas <pth@suse.de> wrote:
> >> >> GNU find will not recognize file systems of type autofs on newer Linux
> >> >> kernels as autofs entries are only listed in /proc/mounts and mountlist.c
> >> >> includes glibc mntent.h which takes the _PATH_MOUNTED from paths.h and that
> >> >> is /etc/mtab.
> >> >>
> >> >> After a longer discussion, we (SUSE) chose to patch mountlist.c in findutils
> >> >> to use proc/mounts instead of /etc/mtab which fixed ou problem.
> >> >>
> >> >> Would gnulib accept the attached patch to mountlist.c?
> >> >
> >> > I don't know if this patch was accepted, but it shouldn't be. The
> >> > problem is that /proc/mounts has incomplete data for /. This will
> >> > break gnulib's mountlist, at least with the current form of the patch,
> >> > because mountlist will have an incorrect idea of the type of the root
> >> > filesystem. Here's an example showing the problem:
> >> >
> >> > ~$ cat tryit.sh
> >> > #! /bin/sh
> >> > f() {
> >> > echo "$1"
> >> > ( ls -l /etc/mtab; find / -maxdepth 0 -printf '%p %F\n' ) |
> >> > sed -e 's_^_ _'
> >> > }
> >> >
> >> > set -e
> >> > cd /etc
> >> > f "regular /etc/mtab"
> >> >
> >> > mv mtab mtab.old; ln -s ../proc/mounts mtab
> >> > f "with /proc/mounts"
> >> > rm mtab; mv mtab.old mtab
> >> > ~$ sudo sh tryit.sh
> >> > regular /etc/mtab
> >> > -rw-r--r-- 1 root root 1869 May 30 23:53 /etc/mtab
> >> > / ext3
> >> > with /proc/mounts
> >> > lrwxrwxrwx 1 root root 14 May 31 01:12 /etc/mtab -> ../proc/mounts
> >> > / rootfs
> >
> >
> > That's strange, why for "/" it does not search in the file (mtab) in reverse
> > order?
> >
> > example A)
> >
> > # mount -t ext3 /dev/sda6 /mnt/test
> > # mount -t ext4 /dev/mapper/kzak-home /mnt/test
> >
> > ... so I have two entries for the same mountpoint:
> >
> > # grep /mnt/test /proc/mounts
> > /dev/sda6 /mnt/test ext3 rw,relatime,errors=continue,barrier=0,data=ordered 0 0
> > /dev/mapper/kzak-home /mnt/test ext4 rw,relatime,barrier=1,data=ordered 0 0
> >
> >
> > this is correct (ext4 is the second entry):
> >
> > # find /mnt/test -maxdepth 0 -printf '%p %F\n'
> > /mnt/test ext4
> >
> >
> > example B)
> >
> > the same thing with root FS:
> >
> > # grep -E '(/dev/sda4|rootfs)' /proc/mounts
> > rootfs / rootfs rw 0 0
> > /dev/sda4 / ext3 rw,noatime,errors=continue,user_xattr,acl,barrier=0,data=ordered 0 0
> >
> > ... so I have two entries for the same mountpoint:
> >
> >
> > # find / -maxdepth 0 -printf '%p %F\n'
> > / rootfs
> >
> > why does it return the first entry? It seems like obvious bug. You
> > have to read entries in the mtab file in reverse order.
>
> I find this claim most surprising, since getmntent is intended for use
> on both /etc/mtab and /etc/fstab and it reads them forwards. As a
> system administrator, I would consider it a bug for there to be a
> duplicate entry in /etc/mtab, and if as a sysadmin I had actually
/dev/sda1 /foo ext2 defaults
/dev/sda2 /foo ext3 defaults
there is nothing duplicated, this maybe unusual, but valid setup
> somehow put two similar entries into /etc/fstab,
Don't care about fstab, you can mount whatever manually and I think
that basic system tools should be able to follow VFS.
> I'd expect mount(8)
> to use the first match (and mount -a to use all matches).
We are not talking about fstab, but about list of already mounted
filesystem. The order is important, because you can mount more
filesystems on the same mountpoint. The visible filesystem is the
filesystem on the top of the hierarchy.
And yes, "mount [-a]" reads fstab in normal order (forward), but when
mount(8) or umount(8) work with lists of the mounted filesystes (e.g.
/etc/mtab, /proc/mounts, /proc/self/mountinfo ) then we use reverse order.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2011-06-01 7:56 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-04-05 12:36 Using /proc/mounts in mountlist.c for linux Philipp Thomas
2011-04-05 14:18 ` Pádraig Brady
2011-04-06 11:03 ` Karel Zak
2011-04-06 11:41 ` Pádraig Brady
2011-05-31 0:14 ` James Youngman
2011-05-31 2:21 ` Paul Eggert
2011-05-31 9:31 ` Pádraig Brady
2011-05-31 9:42 ` James Youngman
2011-05-31 11:10 ` Karel Zak
2011-05-31 23:28 ` James Youngman
2011-06-01 7:56 ` Karel Zak
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).