LDP
/
old-www
1
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity
old-www/LDP/LG/issue82/tag/2.html

457 lines
18 KiB
HTML
Raw Permalink Blame History

<!--startcut ==============================================-->
<!-- *** BEGIN HTML header *** -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML><HEAD>
<META NAME="generator" CONTENT="lgazmail v1.4F.w">
<TITLE>The Answer Gang 82: df -k is confused</TITLE>
</HEAD><BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#0000AF"
ALINK="#FF0000">
<!-- *** END HTML header *** -->
<TABLE width="100%" BORDER><TR><TD WIDTH="200">
<A HREF="http://www.linuxgazette.com/">
<IMG ALT="LINUX GAZETTE" SRC="../../gx/2002/lglogo_200x41.png"
WIDTH="200" HEIGHT="41" border="0"></A>
<BR CLEAR="all">
<SMALL>...<I>making Linux just a little more fun!</I></SMALL>
</TD><TD>
<center>
<img src="../gx/dennis/qbubble.gif" alt="(?)"
border="0" align="left">
<A NAME="answer"><BIG><BIG><STRONG><FONT COLOR="maroon"
>The Answer Gang</FONT></STRONG></BIG></BIG></a>
<img src="../gx/dennis/bbubble.gif" alt="(!)"
border="0" align="right"><BR>
<STRONG>By Jim Dennis, Ben Okopnik, Dan Wilder, Breen, Chris, and...
(<a href="tag/bios.html">meet the Gang</a>) ...
the Editors of <i>Linux Gazette</i>...
and You!
</STRONG></BIG> </TD></TR>
</TABLE>
<P>
<!-- END header -->
<center><p>
<br>We have guidelines for <a href="http://www.linuxgazette.com/tag/ask-the-gang.html">asking</a> and <a href="http://www.linuxgazette.com/tag/members-faq.html">answering</a> questions. <a href="mailto:linux-questions-only@ssc.com">Linux questions only</a>, please.
</STRONG>
<br><em><font color="#7F0000">We make <b>no guarantees</b> about answers, but you can be <b>anonymous</b> on request.</font></em>
<br>See also: The Answer Gang's
<a href="http://www.linuxgazette.com/tag/tag-kb.html">Knowledge Base</a>
and the <i>LG</i>
<a href="http://www.linuxgazette.com/search.html">Search Engine</a>
</center>
<br></p></center>
<HR>
<!-- begin 2 -->
<H3 align="left"><img src="../../gx/dennis/qbubble.gif"
height="50" width="60" alt="(?) " border="0"
>df -k is confused</H3>
<p><strong>From Edgardo Achiardi
</strong></p>
<p align="right"><strong>Answered By Jim Dennis, John Karns, Heather Stern, Jay R. Ashworth, Mike "Iron" Orr, Matthias Posseldt
<p></strong></p>
<!-- sig -->
<!-- sig -->
<P><STRONG>
Hi
</STRONG></P>
<P><STRONG>
I have a problem
</STRONG></P>
<P><STRONG>
I try to boot my disks with Linux, the secondary disk is a copy of primary
disk. I can boot with the secondary, but when I execute 'df -k' show me the
output of primary disk and not the secondary disk.
</STRONG></P>
<P><STRONG>
I need boot with primary and secondary disk, like a backup or in special
case, because if the primary disk is in fault mode I can boot with the
secondary boot, in this way my system to follows brinding service.
</STRONG></P>
<P><STRONG>
Thanks for all
</STRONG></P>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
> [JimD]
I suspect that you have a stale <TT>/etc/mtab</TT> file laying around when you issue
this df command. The df command reads <TT>/etc/mtab</TT> to find out about mount
points, and it easily gets confused by this.
</blockQuote>
<blockQuote>
Make sure that your <TT>/etc/mtab</TT> file is properly truncated during boot, and
that it gets properly populated with your mount information by your rc
scripts. (Obviously the startup (rc) scripts on all general purpose
distributions already do this for you --- so this case only comes up when
you've messed with them, rolled your own, or when you've replicated the
system and/or booted it up in some odd way.
</blockQuote>
<P><STRONG>
<IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
when backup is finished (from primary disk to secondary disk), i corrected
the configuration files and lilo.conf. but when i boot my secondary disk
startup, this process move the configuration files such as mtab. what can i
do for keep this files.
</STRONG></P>
<P><STRONG>
i compile lilo and was succesfully, what happens?
</STRONG></P>
<P><STRONG>
thanks
</STRONG></P>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
> [Heather]
It's not lilo's fault in the slightest.
</blockQuote>
<blockquote><em><font color="#000066">At this point our Answer Gang gleefully leapt upon the question. The actual
answer deals with two files: /etc/fstab, and /etc/mtab.
-- Heather</font></em></blockquote>
<HR width="10%" align="left">
<h4 align="center"><br>/etc/fstab
</h4>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
> [John]
After copying your system to a 2nd disk, you also need to edit <TT>/etc/fstab</TT> to
change the device references from the device that you copied from to point
to the disk that you want to boot from.
</blockQuote>
<blockquote><em><font color="#000066">Snipping a bit of the discussion that led us into a maze of twisty passages,
some incorrect ... the result is nonethless important...
-- Heather</font></em></blockquote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
> [Iron]
Let's stop talking about <TT>/etc/fstab.</TT> We all agree it's a bad idea to create
<TT>/etc/fstab</TT> dynamically from <TT>/proc/mounts.</TT> It may be acceptable for the
sysadmin to do it <EM>once</EM> <EM>manually</EM> before customizing it, but fstab also
contains:
</blockQuote>
<blockQuote><ol>
<LI>the "options" column (see below)
<LI>"noauto" entries (floppies, CD-ROMs, backup repositories), which may not be
currently mounted
<LI>swap partitions, which never show up in /proc/mounts
<LI>comments, especially the one saying which column is what
</ol></blockQuote>
<HR width="10%" align="left">
<h4 align="center"><br>/etc/mtab
</h4>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
> [John]
Also delete <TT>/etc/mtab</TT>, as that will get created when you boot from the new device.
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
> [Matthias]
There are also ways to clear out <TT>/etc/mtab</TT> while booting, but it is
somewhat more difficult.
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
> [Heather]
Here's the trick I use, since I
multi boot and transport whole linuxen around in tarballs a lot.
</blockQuote>
<blockQuote>
Make <TT>/etc/mtab</TT> a symlink to <TT>/proc/mounts.</TT>
</blockQuote>
<blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
> [JimD]
-- dynamically showing the real mount status of all local filesystems.
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
> [jra]
<EM>Showing</EM> them, fine. But if the designers of the system had wanted
you to <EM>depend</EM> on them, it's a reasonably good bet they'd have done
this in the distro's already. Should we ask Linus? Or Erik Troan,
maybe?
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
> [Iron]
The original Unixes didn't have anything equivalent to <TT>/proc</TT>, so they had to
use <TT>/etc/mtab.</TT> The concept of the kernel exposing its internal state through
the filesystem is a relatively recent invention.
</blockQuote>
</blockQuote>
<P><STRONG>
<IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
> [Iron]
Why does "mount" even use mtab if <TT>/proc/mounts</TT> is more accurate? Whenever I
boot into single user mode, the "mount" listing shows the previous boot, not
the current one, because the root filesystem is read-only so it can't update
mtab. But if I remember about <TT>/proc/mounts</TT>, all is well.
</STRONG></P>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
> [JimD]
There has been some debate on this over the years. On the one hand
<TT>/proc</TT> is the canonical way for the Linux kernel to export state (expecially
"PROCess" status) to user space. On the other hand the legacy of the
libraries and other forms of UNIX dictate the <TT>/etc/mtab</TT> file, maintained
by the mount command and read by df, du, and others (including the mount
command when it's used to display the currently mounted filesystems).
</blockQuote>
<blockQuote>
Raising some other limb we could note that there are some cases where
<TT>/proc</TT> is undesirable (particularly in embedded systems). Arguably these
systems already need a different version of the procps suite (which
provides the ps and top commands). If mount relied upon <TT>/proc/mounts</TT>
then these embedded systems would need special versions of that.
</blockQuote>
<blockQuote>
Of course we could increase the cruft support factor. We could have
the appropriate library calls check for <TT>/proc/mounts</TT> and use it
preferentially. They'd then back off to using <TT>/etc/mtab</TT> if <TT>/proc/mounts</TT>
where inaccessible. I can hear Linus retching into a brown paper bag
somewhere --- undoubtedly intent on sticking that over my head to shut
me up on this.
</blockQuote>
<blockQuote>
If we choose <TT>/proc/mounts</TT> uniformly then we have a few problems. First
we have to write some parts of the format in stone --- to properly
decouple future kernel implementation changes from userspace and library
work. (I don't relish the prospect of the sorts of procfs changes that
occured circa 1.3.x which caused older versions of ps to core dump under
new kernels).
</blockQuote>
<blockQuote>
Personally I don't see a problem with that. However, we have to keep in
mind that Linux' filesystem support is likely to change radically over
the next couple of stable kernel versions. We know that Al Viro is
working on implementing "stackable" (or union, or translucent, or
overlay) filesystems and we see a bit more work on LVM and snapshot support
on the horizon. It's not clear how much effect this will have on the
format of <TT>/proc/mounts</TT> --- how much data we'll need to add to it to
support sane userspace semantics.
</blockQuote>
<blockQuote>
So, for now, just consider it to be one of those legacy bugaboos of
Linux. As Heather has said, replacing <TT>/etc/mtab</TT> with a symlink to
<TT>/proc/mounts</TT> seems to mostly work "well enough." Unfortunately I can't
think of examples of how it doesn't work, of things to look out for.
</blockQuote>
<blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
> [Heather]
While there may be some small distro-specific information by the mtab
updaters which is lost, the beauty of knowing that when proc is mounted
during normal bootup, <TT>/etc/mtab</TT> is going to <EM>just work</EM> is worthwhile.
</blockQuote>
<P><STRONG>
<IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
> [Iron]
Like what?
</STRONG></P>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
> [Heather]
I don't know. It just invariably happens in a large enough crowd when
I suggest this symlink trick, someone objects in this way. For all I
know BSDs have some trouble of this sort and it isn't even Linux-y. But
some Linux variants try to do things in a more BSDish way, and if both
of those were so, I'd expect there might be something.
</blockQuote>
<blockQuote>
My first concept is it might list the devices by their e2labels if they
have them, which proc never looks at.
</blockQuote>
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
> [Iron]
I also remember hearing that mtab was the main reason (actually, the only
reason) why leaving the root filesystem read-only all the time was a bad idea.
(Assuming <TT>/tmp</TT> and <TT>/var</TT> are somewhere else, of course.)
</blockQuote>
<blockQuote>
"mount" could, for instance, read <TT>/proc/mounts</TT> if available and fall back to
<TT>/etc/mtab</TT> if not. Likewise, it could write mtab out if it's a regular file
but not if it's a symlink.
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
> [JimD]
The question at hand regards the implication of the latter choice.
What's wrong with making <TT>/etc/mtab</TT> a symlink to <TT>/proc/mounts?</TT> I don't
know. Why do the maintainers of the main kernel and fsutils continue
to do it using a static <TT>/etc/mtab</TT> file? (Legacy?) Are there programming
disadvantages to setting the symlink? (Note: my first question was about
the implications to the sysadmin, this last is about the implications
for the maintainers of the fsutils and other programmers).
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
> [Iron]
I did find one thing in <TT>/etc/mtab</TT> in <A HREF="http://www.debian.org/">Debian</A> that <TT>/proc/mounts</TT> doesn't have:
the "options" column from <TT>/etc/fstab.</TT> Viz:
</blockQuote>
<blockQuote><BLOCKQuote>
% cat <TT>/proc/mounts</TT>
</BLOCKQuote></blockQuote>
<p align="center">See attached <tt><a href="../misc/tag/mike-orr.proc-mounts.txt">mike-orr.proc-mounts.txt</a></tt></p>
<blockQuote>
% cat <TT>/etc/mtab</TT>
</blockQuote>
<p align="center">See attached <tt><a href="../misc/tag/mike-orr.etc-mtab.txt">mike-orr.etc-mtab.txt</a></tt></p>
<blockQuote>
% cat <TT>/etc/fstab</TT>
</blockQuote>
<p align="center">See attached <tt><a href="../misc/tag/mike-orr.etc-fstab.txt">mike-orr.etc-fstab.txt</a></tt></p>
<blockQuote>
Also, since I have devfs in my kernel but it's not mounted, <TT>/proc/mounts</TT> has
a funky line for the root partition.
</blockQuote>
<blockQuote>
None of these differences are significant to me, but any program that parses
<TT>/etc/mtab</TT> would be affected. If there are any programs that parse <TT>/etc/mtab</TT>,
besides the GUI mount dialogs.
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
> [Heather]
On the flip side if you more commonly use the space to chroot into,
then you need to remember to mount the proc filesystem if things care
about it. Many of the finer deamons do, anyway.
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
> [Matthias]
If you try to setup a group of users who can mount and unmount file systems
you are stuck with the dynamic <TT>/proc/mounts</TT> method:
</blockQuote>
<blockquote><pre>/dev/hda5 /mnt/windows-data vfat user,uid=500,gid=500,umask=007 0 0
</pre></blockquote>
<blockQuote>
If mounted by a user who is in group 500 (windows) all members of the group
and root himself can use the file system. But if it comes to unmounting
there are problems if you use the <TT>/proc/mounts-linked-to-/etc/mtab</TT>
approach and therefore are missing the options field: Now only root can
unmount the file system while with a static <TT>/etc/mtab</TT> every member of
group 500 can unmount the partition.
</blockQuote>
<blockQuote>
So you have either option: Use the link approach to not care about correct
<TT>/etc/mtab</TT> in the case your system fails and miss some advanced (u)mount
functionality or use the static approach and be able to use it.
</blockQuote>
<blockQuote>
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
> [Iron]
But it works for me, at least for a user unmounting a partition that has the
"user" option in <TT>/etc/fstab</TT>, even though that column is missing in the
symlinked mtab. The kernel should know which options it's mounted with, whether
that shows up in <TT>/proc/mounts</TT> or not. And one would expect 'umount' to work
parallel to 'mount', which uses fstab information to supply default options.
</blockQuote>
<blockQuote>
Perhaps your system is different, or the vfat filesystem is underfeatured.
</blockQuote>
<!-- end 2 -->
<P> <hr> </p>
<!-- *** BEGIN copyright *** -->
<hr>
<CENTER><SMALL><STRONG>
<h5>
<br>Copyright &copy; 2002
<br>Copying license <A HREF="">http://www.linuxgazette.com/copying.html</A>
<BR>Published in Issue 82 of <i>Linux Gazette</i>, September 2002</H5>
</STRONG></SMALL></CENTER>
<!-- *** END copyright *** -->
<HR>
<!--startcut ======================================================= -->
<P> <hr>
<!-- begin tagnav ::::::::::::::::::::::::::::::::::::::::::::::::::-->
<p align="center">
<table width="100%" border="0"><tr>
<td align="right" valign="center"
><IMG ALT="" SRC="../../gx/navbar/left.jpg"
WIDTH="14" HEIGHT="45" BORDER="0" ALIGN="middle" border="0"
><A HREF="../index.html"
><IMG SRC="../../gx/navbar/toc.jpg" align="middle"
ALT="[ Table Of Contents ]" border="0"></A
><A HREF="../lg_answer.html"
><IMG SRC="../../gx/dennis/answertoc.jpg" align="middle"
ALT="[ Answer Guy Current Index ]" border="0"></A></td>
<td align="center" valign="center"><A HREF="../lg_answer.html#greeting"><img align="middle"
src="../../gx/dennis/smily.gif" alt="greetings" border="0"></A> &nbsp;
<A HREF="../tag/bios.html">Meet&nbsp;the&nbsp;Gang</A> &nbsp;
<A HREF="1.html">1</A> &nbsp;
<A HREF="2.html">2</A>
</td>
<td align="left" valign="center"><A HREF="../../tag/kb.html"
><IMG SRC="../../gx/dennis/answerpast.jpg" align="middle"
ALT="[ Index of Past Answers ]" border="0"></A
><IMG ALT="" SRC="../../gx/navbar/right.jpg" align="middle"
WIDTH="14" HEIGHT="45" BORDER="0"></td></tr></table>
</p>
<!-- end tagnav ::::::::::::::::::::::::::::::::::::::::::::::::::::-->
<!--endcut ========================================================= -->
<P> <hr>
<!--startcut ======================================================= -->
<CENTER>
<!-- *** BEGIN navbar *** -->
<!-- *** END navbar *** -->
</CENTER>
</p>
<!--endcut ========================================================= -->
<!--startcut ======================================================= -->
</BODY></HTML>
<!--endcut ========================================================= -->
Reference in New Issue View Git Blame Copy Permalink