F15: ugly behavior of "df"

[Jeff Spaleta]

> i need NOT to "reset your expectations" because if i would
> start to expect that it is mordern everywhere to replace working
> things with new stuff which is NOT READY i should throw
> away all my computers and search a job in a church

Well you do what you feel is best for you. Working at a church can be
a rewarding experience, it may in fact help you develop a modicum of
empathy for other human beings in a way that living entirely through
electronic interaction cannot. I personally enjoy the time I volunteer
at my church


Anyways....
I've tried to point you to a modicum of historical context to give you
some breadcrumbs to follow to gain some perspective on how long people
(not just our distribution) have been struggling to resolve the
problems associated with relying on /etc/mtab.  The reality is
"mounting" over the years in linux has seen a lot of changes in the
past 10 years with more and more kernel level fake filesystems that
are not attached to block devices show up.  Many people have come to
understand that the best solution to all the problems is to rely on
the kernel's own knowledge of the mount points and to stop relying on
/etc/mstab as constructed artificially which can get out of sync with
the kernel's mounting information.

Some of the historic problems with relying on mtab has been encoded in
the mount manpage for awhile now(well before Fedora even considered
moving away from mtab) and I've personally pointed you to an upstream
list discussion concerning the problems relying on mtab dating back to
2007.

And to be clear Fedora isn't the first distribution to turn /etc/mtab
into a symlink. Hell, even _historic_ "linux from scratch" manual has
instructions that tell people to turn mtab into a symlink into
/proc/mounts.

http://archive.linuxfromscratch.org/lfs-museum/3.3/LFS-BOOK-3.3-HTML/index.html

That dates from 2003!!!!!! 2003!!!!!!! There have been people out
there, smart do-it-yourselfers working with LFS to build up their own
linux distro from sources who have been making the very change that is
frustrating you in 2003.


is there a problem with bind mount handling? Yes  Was it caught in
testing? Seems like it wasn't.  Does Fedora make any effort to test
bind mounts as part of organized pre-release QA? I'm not aware that we
do as our pre-release QA is quite narrowly scoped to ensure default
install configs as we don't have the resources to test all possible
configurations and command options.  Did anyone who makes use of bind
mounts day to day in our userbase flag this ahead of release? I didn't
and I really can't lay the blame at the feet of developers for
shipping something "not ready" when I myself, who was actively testing
for breakage, didn't catch this.

And make no mistake the solution to bind mount handling and
representation moving forward will not depend on reverting to using
the constructed information in /etc/mtab and will have to depend on
the kernel's /proc/mounts.  Tools that relied on mtab's understanding
of what a bind mount was (and it seems also the user option if I'm
reading the mount manpage correctly.) There has been years of
discussion on the issue of mtab versus /proc/mounts outside of our
specific distribution channels, and there is no getting around it that
the long term solution is to rely on the kernel's own representation
of mounts.


Though I wonder, since /etc/mtab is just a symlink. is the mount
command we ship still able to write to /etc/mtab if a local admin
decided to revert and make /etc/mtab a normal file again.  Would our
mount command then update that file as per the legacy way? because
really that is exactly what you want to do on your system.   If our
mount command will still attempt to write to /etc/mtab once its a real
file again, maybe things will work for you as expected.

-jef









You've only taken notice because its finally impacted you.


I think its ready enough to ship


I believe your definition of ready is incompatible with the release
model Fedora has chosen.

Your expectation is that new things work exactly the same and have
detailed backwards compatability. That's hasn't been true _ever_ in
any system I've had the pleasure of doing upgrades across major
releases.

windows, qnx,vms,mac os, linux.... tons and tons and tons of subtle
syntax channges in shipped functionality that resulted in breakage in
my "working" code on all those systems in different places at
different times.