...making Linux just a little more fun!

The Answer Gang By Jim Dennis, Ben Okopnik, Dan Wilder, Breen, Chris, and... (meet the Gang) ... the Editors of Linux Gazette... and You!

df -k is confused

From Edgardo Achiardi

Answered By Jim Dennis, John Karns, Heather Stern, Jay R. Ashworth, Mike "Iron" Orr, Matthias Posseldt

Hi

I have a problem

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.

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.

Thanks for all

[JimD] I suspect that you have a stale /etc/mtab file laying around when you issue this df command. The df command reads /etc/mtab to find out about mount points, and it easily gets confused by this.

Make sure that your /etc/mtab 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.

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.

i compile lilo and was succesfully, what happens?

thanks

[Heather] It's not lilo's fault in the slightest.

At this point our Answer Gang gleefully leapt upon the question. The actual answer deals with two files: /etc/fstab, and /etc/mtab. -- Heather

/etc/fstab

[John] After copying your system to a 2nd disk, you also need to edit /etc/fstab to change the device references from the device that you copied from to point to the disk that you want to boot from.

Snipping a bit of the discussion that led us into a maze of twisty passages, some incorrect ... the result is nonethless important... -- Heather

[Iron] Let's stop talking about /etc/fstab. We all agree it's a bad idea to create /etc/fstab dynamically from /proc/mounts. It may be acceptable for the sysadmin to do it once manually before customizing it, but fstab also contains:

1. the "options" column (see below)
2. "noauto" entries (floppies, CD-ROMs, backup repositories), which may not be currently mounted
3. swap partitions, which never show up in /proc/mounts
4. comments, especially the one saying which column is what

/etc/mtab

[John] Also delete /etc/mtab, as that will get created when you boot from the new device.

[Matthias] There are also ways to clear out /etc/mtab while booting, but it is somewhat more difficult.

[Heather] Here's the trick I use, since I multi boot and transport whole linuxen around in tarballs a lot.

Make /etc/mtab a symlink to /proc/mounts.

[JimD] -- dynamically showing the real mount status of all local filesystems.

[jra] Showing them, fine. But if the designers of the system had wanted you to depend 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?

[Iron] The original Unixes didn't have anything equivalent to /proc, so they had to use /etc/mtab. The concept of the kernel exposing its internal state through the filesystem is a relatively recent invention.

[Iron] Why does "mount" even use mtab if /proc/mounts 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 /proc/mounts, all is well.

[JimD] There has been some debate on this over the years. On the one hand /proc 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 /etc/mtab 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).

Raising some other limb we could note that there are some cases where /proc 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 /proc/mounts then these embedded systems would need special versions of that.

Of course we could increase the cruft support factor. We could have the appropriate library calls check for /proc/mounts and use it preferentially. They'd then back off to using /etc/mtab if /proc/mounts 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.

If we choose /proc/mounts 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).

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 /proc/mounts --- how much data we'll need to add to it to support sane userspace semantics.

So, for now, just consider it to be one of those legacy bugaboos of Linux. As Heather has said, replacing /etc/mtab with a symlink to /proc/mounts 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.

[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, /etc/mtab is going to just work is worthwhile.

[Iron] Like what?

[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.

My first concept is it might list the devices by their e2labels if they have them, which proc never looks at.

[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 /tmp and /var are somewhere else, of course.)

"mount" could, for instance, read /proc/mounts if available and fall back to /etc/mtab if not. Likewise, it could write mtab out if it's a regular file but not if it's a symlink.

[JimD] The question at hand regards the implication of the latter choice. What's wrong with making /etc/mtab a symlink to /proc/mounts? I don't know. Why do the maintainers of the main kernel and fsutils continue to do it using a static /etc/mtab 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).

[Iron] I did find one thing in /etc/mtab in Debian that /proc/mounts doesn't have: the "options" column from /etc/fstab. Viz:

% cat /proc/mounts

See attached mike-orr.proc-mounts.txt

% cat /etc/mtab

See attached mike-orr.etc-mtab.txt

% cat /etc/fstab

See attached mike-orr.etc-fstab.txt

Also, since I have devfs in my kernel but it's not mounted, /proc/mounts has a funky line for the root partition.

None of these differences are significant to me, but any program that parses /etc/mtab would be affected. If there are any programs that parse /etc/mtab, besides the GUI mount dialogs.

[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.

[Matthias] If you try to setup a group of users who can mount and unmount file systems you are stuck with the dynamic /proc/mounts method:

/dev/hda5	/mnt/windows-data	vfat	user,uid=500,gid=500,umask=007	0 0

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 /proc/mounts-linked-to-/etc/mtab approach and therefore are missing the options field: Now only root can unmount the file system while with a static /etc/mtab every member of group 500 can unmount the partition.

So you have either option: Use the link approach to not care about correct /etc/mtab in the case your system fails and miss some advanced (u)mount functionality or use the static approach and be able to use it.

[Iron] But it works for me, at least for a user unmounting a partition that has the "user" option in /etc/fstab, 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 /proc/mounts or not. And one would expect 'umount' to work parallel to 'mount', which uses fstab information to supply default options.

Perhaps your system is different, or the vfat filesystem is underfeatured.

Meet the Gang   1   2