FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 01-01-1970, 01:00 AM
"Alan Curry"
 
Default bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

jidanni@jidanni.org writes:
>
> Filesystem 1K-blocks Used Available Use% Mounted on
> rootfs 1071468 287940 729100 29% /
> /dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78 1071468 287940 729100 29% /

(I'm replying only on the issue of the duplicate mount point. Someone else
can tackle the long ugly name.)

The one with "rootfs" as its device is the initramfs which you automatically
get with all recent kernels. Even if you aren't using an initramfs, there's
an empty one built into the kernel which gets mounted as the first root
filesystem. The real root gets mounted on top of that.

So this is a special case of a general problem with no easy solution: What
should df do when 2 filesystems are mounted at the same location? It can't
easily give correct information for both of them, since the later mount
obscures the earlier mount from view.

If there's a way for df to get the correct information for the lower mount, I
don't know what it would be. If you have a process with a leftover cwd or
open fd in the obscured filesystem, you can use that. But generally you
won't.

But maybe we could do better than reporting incorrectly that the lower mount
has size and usage identical to the upper mount! At least df could print a
warning at the end if it has seen any duplicate entries. Perhaps there is
some way it could figure out which one is on top, and print a bunch of
question marks as the lower mount's statistics.

If df is running as root, it might be able to unshare(2) the mount namespace,
unmount the upper level, and then statfs the mount point again to get the
correct results for the lower level. That won't work in all cases (even in a
private namespace you can't unmount the filesystem containing your own cwd)
and it does nothing for you if you're not root, but still... it would be a
cool bonus in the cases where it does work.

As a special case, "rootfs" should probably be excluded from the default
listing, since the initramfs is not very interesting most of the time. It
could still be shown with the -a option, although it would always have the
wrong statistics. Or if you really want to be impressive, default to showing
the initramfs if and only if it is the only thing mounted on "/" - so you can
run df within the initramfs before the real root is mounted and get the right
result.

Or... (brace yourself for the most bold idea yet)... can you imagine a kernel
interface that would *cleanly* give access to obscured mount points?

Comments on any of the above? Do the BSDs have any bright ideas we can steal,
or is their df as embarrassingly bad at handling obscured mount points as
ours?

--
Alan Curry


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111226232705.29921.qmail@kosh.dhis.org">http://lists.debian.org/20111226232705.29921.qmail@kosh.dhis.org
 
Old 12-29-2011, 05:28 PM
Olaf Titz
 
Default bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

> So this is a special case of a general problem with no easy solution: What
> should df do when 2 filesystems are mounted at the same location? It can't
> easily give correct information for both of them, since the later mount
> obscures the earlier mount from view.

It is a special case of an even more general problem, that mtab or
/proc/self/mounts and therefore mount(8), df(1) etc. only represent the
linear path where a filesystem was mounted at the time it was mounted,
not the underlying tree structure.

What happens with the following sequences, assuming / is the only
mounted filesystem:

mkdir /mnt/p1
mount /dev/sde1 /mnt/p1
mkdir /mnt/p1/p2
mount /dev/sdh1 /mnt/p1/p2

versus

mkdir -p /mnt/p1/p2
mount /dev/sdh1 /mnt/p1/p2
mount /dev/sde1 /mnt/p1

not that that would be very useful, but in general it is possible. In
the second case the filesystem on sdh1 is completely invisible, yet
mtab and /proc/mounts in both cases contain something like

/dev/sde1 /mnt/p1 ...
/dev/sdh1 /mnt/p1/p2 ...

only in different order: the last mounted filesystem comes last.

This way df(1) should already be able to just hide any obscured
filesystem: it could make two passes over the mount list, remembering
every mount point and if a later mount point is equal or a parent of
an earlier one (which can be determined by a simple string compare),
mark the earlier one as invisible. Then in the second pass over the
list output the remaining mounts.

Remains the question whether this is correct in all cases and actually
desirable behaviour. I think the latter is true, because df(1) output
is just a snapshot of how the system looks like to a newly created
process, and a newly created process can't access the obscured
filesystems at all. (The fact that /proc/mounts is a symlink to
/proc/self/mounts hints in the same direction.)

If what's really wanted is the status of all mounted filesystems
whether visible or not, I fear this can't be done without kernel help,
because exactly by the "snapshot as seen by a new process" nature you
don't get a handle to statfs() from the obscured parts. They can be
found by looking in /sys/block or /proc/diskstats but there doesn't
seem to be useful info, perhaps just another sysfs file containing the
statfs() output would already suffice.

Or perhaps just propose that one of the three nearly-identical
/proc/self/mount* files get two additional columns with the info df(1)
needs...

Olaf


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: E1RgKih-00041L-Ec@bigred.inka.de">http://lists.debian.org/E1RgKih-00041L-Ec@bigred.inka.de
 
Old 01-18-2012, 01:25 PM
Goswin von Brederlow
 
Default bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

"Alan Curry" <pacman-cu@kosh.dhis.org> writes:

> jidanni@jidanni.org writes:
>>
>> Filesystem 1K-blocks Used Available Use% Mounted on
>> rootfs 1071468 287940 729100 29% /
>> /dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78 1071468 287940 729100 29% /
>
> (I'm replying only on the issue of the duplicate mount point. Someone else
> can tackle the long ugly name.)
>
> The one with "rootfs" as its device is the initramfs which you automatically
> get with all recent kernels. Even if you aren't using an initramfs, there's
> an empty one built into the kernel which gets mounted as the first root
> filesystem. The real root gets mounted on top of that.
>
> So this is a special case of a general problem with no easy solution: What
> should df do when 2 filesystems are mounted at the same location? It can't
> easily give correct information for both of them, since the later mount
> obscures the earlier mount from view.

The problem also exists in a larger extend with chroots. There will be
lots of entries from outside the chroot that are inaccessible to a df
running inside the chroot.

What df should do is automatically skip the entries that are obscured or
generally inaccessible. Unfortunately the kernel does not (re)sort the
entries correctly following a mount --move call:

rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
none /proc proc rw,nosuid,nodev,noexec,relatime 0 0
none /dev devtmpfs rw,relatime,size=491516k,nr_inodes=122879,mode=755 0 0
none /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode= 000 0 0
/dev/mapper/s-root / ext3 ro,relatime,errors=remount-ro,data=ordered 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,relatime,mode=755 0 0
...

Going by that list the /dev/mapper/s-root filesystems obscures the
rootfs, /sys, /proc, /dev and /dev/pts. In reality though only the
rootfs is obscured because the rest was moved prior to the initramfs
switching / around. What the kernel should do is move the relevant
entries so they appear below the filesystem they are moved to (and
before any that do obscure them, moving them to the bottom isn't always
the right solution).

So at the moment is a bit of a guess which entries are real and which
are obscured. The best you can do is check that each entry is actually a
mountpoint and guess that the last of identical mountpoints is the right
one.

> If there's a way for df to get the correct information for the lower mount, I
> don't know what it would be. If you have a process with a leftover cwd or
> open fd in the obscured filesystem, you can use that. But generally you
> won't.

There afaik isn't and there should not be a way to do so.

> But maybe we could do better than reporting incorrectly that the lower mount
> has size and usage identical to the upper mount! At least df could print a
> warning at the end if it has seen any duplicate entries. Perhaps there is
> some way it could figure out which one is on top, and print a bunch of
> question marks as the lower mount's statistics.

Maybe compare the major/minor of the device node with statfs() output.

> If df is running as root, it might be able to unshare(2) the mount namespace,
> unmount the upper level, and then statfs the mount point again to get the
> correct results for the lower level. That won't work in all cases (even in a
> private namespace you can't unmount the filesystem containing your own cwd)
> and it does nothing for you if you're not root, but still... it would be a
> cool bonus in the cases where it does work.
>
> As a special case, "rootfs" should probably be excluded from the default
> listing, since the initramfs is not very interesting most of the time. It
> could still be shown with the -a option, although it would always have the
> wrong statistics. Or if you really want to be impressive, default to showing
> the initramfs if and only if it is the only thing mounted on "/" - so you can
> run df within the initramfs before the real root is mounted and get the right
> result.

What if you only have a rootfs?

Imho the /proc/mounts file should only contain entries visible in the
processes mount namespace. So for normal systems the rootfs shouldn't
appear and in chroots the list should be even shorter.

> Or... (brace yourself for the most bold idea yet)... can you imagine a kernel
> interface that would *cleanly* give access to obscured mount points?

I fear that would let too much information escape from/into the mount
namesapces.

But there could be a /proc/global-mounts or something that is only
readable from the root namespace.

> Comments on any of the above? Do the BSDs have any bright ideas we can steal,
> or is their df as embarrassingly bad at handling obscured mount points as
> ours?

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87k44p9jge.fsf@frosties.localnet">http://lists.debian.org/87k44p9jge.fsf@frosties.localnet
 
Old 01-18-2012, 05:12 PM
Paul Eggert
 
Default bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

On 01/18/12 06:25, Goswin von Brederlow wrote:
> What df should do is automatically skip the entries that are obscured or
> generally inaccessible.

Isn't this missing some of the larger context? df is just doing what
lots of other programs do: finding out what file systems one has,
and reporting statistics on them. It sounds suboptimal to require
the maintainers of all these programs (coreutils, nautilus, etc.)
to rewrite their apps to deal with obscured entries. Surely it would
be better to have the kernel ordinarily return just the ordinary entries,
and to return obscured entries only when they are specially requested.
That way, this issue would be isolated to the few bits of code that really
want to see obscured entries.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F170B94.3010304@cs.ucla.edu">http://lists.debian.org/4F170B94.3010304@cs.ucla.edu
 
Old 01-19-2012, 08:57 AM
Goswin von Brederlow
 
Default bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 01/18/12 06:25, Goswin von Brederlow wrote:
>> What df should do is automatically skip the entries that are obscured or
>> generally inaccessible.
>
> Isn't this missing some of the larger context? df is just doing what
> lots of other programs do: finding out what file systems one has,
> and reporting statistics on them. It sounds suboptimal to require
> the maintainers of all these programs (coreutils, nautilus, etc.)
> to rewrite their apps to deal with obscured entries. Surely it would
> be better to have the kernel ordinarily return just the ordinary entries,
> and to return obscured entries only when they are specially requested.
> That way, this issue would be isolated to the few bits of code that really
> want to see obscured entries.

+1. Kernel knows best anyway.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 877h0o9fr1.fsf@frosties.localnet">http://lists.debian.org/877h0o9fr1.fsf@frosties.localnet
 
Old 01-19-2012, 10:23 AM
Henrique de Moraes Holschuh
 
Default bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

On Thu, 19 Jan 2012, Goswin von Brederlow wrote:
> Paul Eggert <eggert@cs.ucla.edu> writes:
> > On 01/18/12 06:25, Goswin von Brederlow wrote:
> >> What df should do is automatically skip the entries that are obscured or
> >> generally inaccessible.
> >
> > Isn't this missing some of the larger context? df is just doing what
> > lots of other programs do: finding out what file systems one has,
> > and reporting statistics on them. It sounds suboptimal to require
> > the maintainers of all these programs (coreutils, nautilus, etc.)
> > to rewrite their apps to deal with obscured entries. Surely it would
> > be better to have the kernel ordinarily return just the ordinary entries,
> > and to return obscured entries only when they are specially requested.
> > That way, this issue would be isolated to the few bits of code that really
> > want to see obscured entries.
>
> +1. Kernel knows best anyway.

The kernel has to return all entries that are visible to the current
namespace, otherwise you pretty much cannot know about the existence of
shadowed entries in the first place, and that has all sort of nasty
implications for security and troubleshooting.

The kernel should NOT include entries that are out of reach due to
namespaces or chrooting, but I don't think this is quite correct right now.

If you don't want to show to the user shadowed entries, fix it in the
UI, maybe write a nice LGPL lib and get the various GNU utils to use it
to avoid duplicated effort... or fix it in glibc, if applicable. But
/proc/mounts really has to return complete information.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120119112300.GA20405@khazad-dum.debian.net">http://lists.debian.org/20120119112300.GA20405@khazad-dum.debian.net
 
Old 01-20-2012, 06:42 AM
Goswin von Brederlow
 
Default bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

Henrique de Moraes Holschuh <hmh@debian.org> writes:

> On Thu, 19 Jan 2012, Goswin von Brederlow wrote:
>> Paul Eggert <eggert@cs.ucla.edu> writes:
>> > On 01/18/12 06:25, Goswin von Brederlow wrote:
>> >> What df should do is automatically skip the entries that are obscured or
>> >> generally inaccessible.
>> >
>> > Isn't this missing some of the larger context? df is just doing what
>> > lots of other programs do: finding out what file systems one has,
>> > and reporting statistics on them. It sounds suboptimal to require
>> > the maintainers of all these programs (coreutils, nautilus, etc.)
>> > to rewrite their apps to deal with obscured entries. Surely it would
>> > be better to have the kernel ordinarily return just the ordinary entries,
>> > and to return obscured entries only when they are specially requested.
>> > That way, this issue would be isolated to the few bits of code that really
>> > want to see obscured entries.
>>
>> +1. Kernel knows best anyway.
>
> The kernel has to return all entries that are visible to the current
> namespace, otherwise you pretty much cannot know about the existence of
> shadowed entries in the first place, and that has all sort of nasty
> implications for security and troubleshooting.
>
> The kernel should NOT include entries that are out of reach due to
> namespaces or chrooting, but I don't think this is quite correct right now.
>
> If you don't want to show to the user shadowed entries, fix it in the
> UI, maybe write a nice LGPL lib and get the various GNU utils to use it
> to avoid duplicated effort... or fix it in glibc, if applicable. But
> /proc/mounts really has to return complete information.

But isn't the rootfs out of reach because the initramfs "chroots" to the
real root and starts /sbin/init? Back when pivot_root was used that
was combined with an actual call to chroot. Before run-init combined the
two.

I'm not realy disagreeing with you but argue that the duplicate rootfs
entry is not visible to the namespace.

Same with later chroots:

mrvn@frosties:~/chroot% sudo chroot . df
df: `/sys': No such file or directory
df: `/dev': No such file or directory
df: `/dev/pts': No such file or directory
df: `/run': No such file or directory
df: `/tmp': No such file or directory
df: `/usr': No such file or directory
df: `/var': No such file or directory
df: `/home': No such file or directory
df: `/var/lib/nfs/rpc_pipefs': No such file or directory
df: `/sys/fs/fuse/connections': No such file or directory
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 1789128 1808 1787320 1% /
/dev/mapper/r-root 1789128 1808 1787320 1% /
tmpfs 1789128 1808 1787320 1% /

What it should show is only the last entry, the tmpfs the chroot is
on. All other entries are not visible to the processes inside the
chroot.

Note that in a chroot any mountpoints inside the chroot have their
prefix removed (/home/mrvn/chroot becomes /) while others are left as
is. That is wrong too IMHO. The filesystem the chroots / is on should
become / even if the chroot is a directory instead of a mountpoint and
entries outside the chroot should not be listed at all.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 874nvqn7kt.fsf@frosties.localnet">http://lists.debian.org/874nvqn7kt.fsf@frosties.localnet
 
Old 01-20-2012, 10:10 AM
Andreas Schwab
 
Default bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

Goswin von Brederlow <goswin-v-b@web.de> writes:

> Note that in a chroot any mountpoints inside the chroot have their
> prefix removed (/home/mrvn/chroot becomes /) while others are left as
> is. That is wrong too IMHO. The filesystem the chroots / is on should
> become / even if the chroot is a directory instead of a mountpoint and
> entries outside the chroot should not be listed at all.

You can get such a view from /proc/self/mountinfo.

Andreas.

--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: m2pqee8w9s.fsf@igel.home">http://lists.debian.org/m2pqee8w9s.fsf@igel.home
 
Old 01-20-2012, 04:41 PM
Henrique de Moraes Holschuh
 
Default bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

On Fri, 20 Jan 2012, Goswin von Brederlow wrote:
> Henrique de Moraes Holschuh <hmh@debian.org> writes:
> > The kernel has to return all entries that are visible to the current
> > namespace, otherwise you pretty much cannot know about the existence of
> > shadowed entries in the first place, and that has all sort of nasty
> > implications for security and troubleshooting.
> >
> > The kernel should NOT include entries that are out of reach due to
> > namespaces or chrooting, but I don't think this is quite correct right now.

...

> But isn't the rootfs out of reach because the initramfs "chroots" to the
> real root and starts /sbin/init? Back when pivot_root was used that
> was combined with an actual call to chroot. Before run-init combined the
> two.

That's what I meant with "I don't think this is quite correct right
now".

> I'm not realy disagreeing with you but argue that the duplicate rootfs
> entry is not visible to the namespace.

I am not sure how /proc/mounts and friends should play with chroot(). I
suppose it depends on whether one can actually reach that path somehow.
If it is forever unacessible, IMO it is effectively outside the
namespace and I believe it should not be visible. But that's where I
reach the limits of my knowledge, and I can't really argue about it.

> What it should show is only the last entry, the tmpfs the chroot is
> on. All other entries are not visible to the processes inside the
> chroot.

I think you're correct in this.

> Note that in a chroot any mountpoints inside the chroot have their
> prefix removed (/home/mrvn/chroot becomes /) while others are left as
> is. That is wrong too IMHO. The filesystem the chroots / is on should
> become / even if the chroot is a directory instead of a mountpoint and
> entries outside the chroot should not be listed at all.

I also think you're correct here, but as I said, chroot() is tricky, and
I am wary of arguing too much about it without strong knowledge about
the nuances, which I don't have.

Maybe this thread really ought to move to linux-fsdevel or LKML?

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120120174128.GB18413@khazad-dum.debian.net">http://lists.debian.org/20120120174128.GB18413@khazad-dum.debian.net
 

Thread Tools




All times are GMT. The time now is 04:20 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org