Re: Using /proc/mounts in mountlist.c for linux

Re: Using /proc/mounts in mountlist.c for linux

[Pádraig Brady]

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.

Re: Using /proc/mounts in mountlist.c for linux

[James Youngman]

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.

Re: Using /proc/mounts in mountlist.c for linux

[Karel Zak]

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

Re: Using /proc/mounts in mountlist.c for linux

[James Youngman]

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
>

Re: Using /proc/mounts in mountlist.c for linux

[Karel Zak]

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