Package: mount
Version: 2.12r-10
Severity: important
Hi guys,
A recent apt-get update gave me a new version of mount that reports
"none" as the filesystem type for bind mounts in /etc/mtab. This causes
those mount points to be supressed in the output of df. I suppose this
behaviour is intended to make life easier for people like me who have a
lot of bind mounts, by supressing redundant information, but this lead
to severe data loss in my case.
I do understand that the mount command is supposed to report mounts,
and df is supposed to display filesystem usage, but I always use df
to do both jobs, since (until now) df always reported the relevant part
of the output of mount, and the output of mount is butt-ugly and
harder to read, and the mount command takes longer to type. I believe
that lots of other people also use df in place of mount.
I had an old chroot used for testing with 9 other filesystems bind mounted
under it. I hadn't used it since before the mount behaviour change, so
when I typed 'df' and saw no mounts reported under the chroot I assumed I
had disabled them at some point in the past, and just forgotten about it.
The morning of the Thursday before last I was about to run my normal
tape backup when I noticed that according to 'df' I had too much data
to fit on my tape, so I decided to rm -r the chroot to make room since
it wasn't really being used anymore. After 15 minutes or so I said
"man this is taking a long time" and ctrl-z paused it, to examine what
was up. Well I had just completely deleted 6 entire filesystems, and was
halfway through deleting my /home filesystem, the very thing I was trying
to backup! If I hadn't stopped it I would have lost over a terrabyte of
data, most of which I have no backup of (I'm not rich enough to have a
terrabyte tape drive).
Luckily I had complete backups of the 6 and a half filesystems that
were deleted from about a month prior, and I am happy to report that
after a week of writing custom data recovery tools and restoring from
previous backups I have gotten back nearly 100% of what I lost, but
I am still kinda mad about what happened, but there is nobody to be
legitimately mad at. The responsibility for the 'bad' behaviour falls
between mount and df, and was probably done to fix a complaint from
a user that bind mounts were wasting their screen space. There has to
be a better way for df to supress filesystems than the existing binary
"remote" and "dummy" flags.
df treats a mount with fstype="none" as a dummy filesystem. There is
probably not a debian-specified definition of dummy filesystem, but I
would assume a dummy filesystem is one which is not intended to be used
for persistant storage, whereas my bind mounts are absolutely intended
as persistant storage.
There are lots of ways to 'fix' this by preserving the old behaviour,
while allowing the new behavior for people who prefer it.
As a user I have:
1) Stopped using "df" or "mount", and resorted to "cat /proc/mounts"
in paranoid fear for a week.
2) Replaced the df binary with a script to call "df -a" which includes
all the filesystems df used to report, plus a bunch of extra crap. This
doesn't give me the output I want (the old output I used to get from
df), but at least won't have me go through the same ordeal again.
I ran "chattr +i" on the script so dpkg can't replace it with another
df with strange behaviour. Of course, now apt-get upgrade fails on
coreutils and require manual intervention.
The package maintaners could:
1a) change df so it has a smarter method of deciding what mounts to leave
out by default, possibly using a config file or environment var. Also
it would be nice to be able to have more control of this on the command
line i.e. use a config file to display everything by default, then
supressing things via command line params (currently the commandline
can only increase the filesystems which are reported, except for network
filesystems, which can be left out. In fact df will not accept multiple
filesystem types to display with the -t option).
1b) change mount to not write "none" as the fstype for bind mounts.
together with 1a this gives all the control to df.
2) There could be an extra flag in /etc/fstab to mark a filesystem as a
not-a-dummy fs, which would translate into mount not writing "none" as
the fstype in /etc/mtab. This gives the control to mount.
3) There could be an env_var that switches the behaviour of mount for
writing "none" or "bind" or "$underlying_fstype" as fstype for bind mounts.
This also gives the control to mount.
4) tell me to jump in the lake and this is a wontfix bug.
I would file a duplicate bug repor against coreutils, but I don't want
to make so much work for the maintainers. If y'all think this is
wontfix for mount, would you consider re-assigning it to coreutils?
Thanks for debian.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17.6
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages mount depends on:
ii libblkid1 1.39-1 block device id library
ii libc6 2.3.6-15 GNU C Library: Shared libraries
ii libuuid1 1.39-1 universally unique id library
mount recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
