df ignores fs type none in options
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
coreutils (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
df appears to ignore the filesystem type "none" when specifying options on the command line. Some example output:
gecko@magina ~> df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 16018264 5669900 9534672 38% /
none 2020908 652 2020256 1% /dev
none 2028632 68 2028564 1% /dev/shm
none 2028632 440 2028192 1% /var/run
none 2028632 0 2028632 0% /var/lock
/dev/sdb6 457072296 42896024 390958336 10% /home
[four different "none" systems]
gecko@magina ~> df -x none
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 16018264 5669900 9534672 38% /
none 2020908 652 2020256 1% /dev
none 2028632 68 2028564 1% /dev/shm
none 2028632 440 2028192 1% /var/run
none 2028632 0 2028632 0% /var/lock
/dev/sdb6 457072296 42896032 390958328 10% /home
[would expect "none" systems not to appear]
gecko@magina ~> df -t none
df: no file systems processed
[would expect only "none" systems to appear]
I have no idea on whether this behaviour is intentional, however I do know that it causes a minor bug to appear in the munin package - the df plugin is unable to ignore a bunch of filesystems even though it is configured to do so by default.
ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: coreutils 8.5-1ubuntu6
ProcVersionSign
Uname: Linux 2.6.38-10-generic x86_64
Architecture: amd64
Date: Tue Sep 6 23:48:25 2011
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429)
ProcEnviron:
LANGUAGE=en_GB:en
PATH=(custom, user)
LANG=en_GB.UTF-8
SHELL=
SourcePackage: coreutils
UpgradeStatus: Upgraded to natty on 2011-08-04 (33 days ago)
Modern df lists the actual fs types for those 'none' devices. E.g. udev, tmpfs, et al. I'm guessing the reason that '-x none' was not excluding them in this old df version was because the type wasn't literally 'none' but perhaps \0 or else was just not being displayed.
In any case, I no longer am reproducing this very old bug, so am closing it out as fixed.