I have created a DAV Filesystem on my machine n22 into the ramdisk, I can access succesfully the DAV repository via cadaver or via mount.davfs2. My ramdisk has 660 MB, the DAV is defined as: ... Alias /davfs /mnt/ramdisk/dav/fs <Location /davfs> ... I am wondering about the displayed free disk space: n22 ~ # df -m /mnt/ramdisk/dav/ /mnt/dav/ Filesystem 1M-blocks Used Available Use% Mounted on tmpfs 660 1 660 1% /mnt/ramdisk http://n22/davfs/ 8790 0 8790 0% /mnt/dav Why there seems to be ~8,8 GB space free whereas the whole ramdisk has only 660 MB ? Reproducible: Always Steps to Reproduce: 1. 2. 3. n22 /etc/apache2/conf/modules.d # emerge info Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r1, 2.6.12-gentoo-r10 i686) ================================================================= System uname: 2.6.12-gentoo-r10 i686 Intel(R) Pentium(R) M processor 1700MHz Gentoo Base System version 1.6.13 ccache version 2.3 [enabled] dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium3 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium3 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://pandemonium.tiscali.de/pub/gentoo/ http://mir.zyrianes.net/gentoo/ http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/" LINGUAS="de en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="x86 X acpi aim alsa apache2 arts avi berkdb bitmap-fonts browserplugin cardbus cddb cdparanoia crypt cups curl dvd dvdr dvdread eds emboss encode ethereal fam font-server foomaticdb fortran gd gdbm gif gpm gstreamer gtk gtk2 imagemagick imlib innodb ipv6 jai java javascript jimi jpeg junit kde libg++ libwww live mad mbox mikmod mmx mmxext mng motif mp3 mpeg mysql nagios-dns nagios-ntp nagios-ping nagios-s ncurses network nls no-old-linux nsplugin ogg oggvorbis opengl oss pam pcmcia pdflib perl png python qt quicktime readline real samba sdl slp smime snmp spell sse sse2 ssl subversion svg tcltk tcpd tiff truetype truetype-fonts type1-fonts usb userlocales vorbis webdav wifi xanim xfs xine xml2 xmms xv zlib linguas_de linguas_en userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY
Can you pelase report this bug upstream to the davfs developers? They have a good mailinglist :)
done http://sourceforge.net/tracker/index.php?func=detail&aid=1311177&group_id=26275&atid=386747 :-)
cool, thanks Toralf. But it seems they have not noticed it. So if you want you can send something to the mailinglist where the authors usually hang around.
Reopend, because it is not a bug of coreutils. Here is the answer from Paul Eggert <eggert@cs.ucla.edu> from the mailing list bug-coreutils@gnu.org : So it's a problem with glibc ? Toralf F
Reopend, because it is not a bug of coreutils. Here is the answer from Paul Eggert <eggert@cs.ucla.edu> from the mailing list bug-coreutils@gnu.org : So it's a problem with glibc ? Toralf Förster <toralf.foerster@gmx.de> writes: > n22 # df -m /mnt/ramdisk/dav/ /mnt/dav_n22/ > Filesystem 1M-blocks Used Available Use% Mounted on > tmpfs 660 1 660 1% /mnt/ramdisk > http://n22/davfs@n22/ > 8790 0 8790 0% /mnt/dav_n22 > n22 # strace -e statfs64 df -m /mnt/ramdisk/dav/ /mnt/dav_n22/ > statfs64("/mnt/ramdisk", 84, {f_type=0x1021994, f_bsize=4096, f_blocks=168960, > f_bfree=168956, f_bavail=168956, f_files=129449, f_ffree=129441, f_fsid={0, > 0}, f_namelen=255, f_frsize=4096}) = 0 > statfs64("/mnt/dav_n22", 84, {f_type="CODA_SUPER_MAGIC", f_bsize=1024, > f_blocks=9000000, f_bfree=9000000, f_bavail=9000000, f_files=9000000, > f_ffree=9000000, f_fsid={0, 0}, f_namelen=255, f_frsize=1024}) = 0 statfs64 is claiming that /mnt/dav_n22 has 9000000 blocks, each of size 1024 bytes. That adds up to 8789.0625 MiB, and so the "8790" is correct (as df always rounds up) if statfs64 is correct. You mentioned that the file system actually has only 660 MB, so it sounds like statfs64 is reporting the wrong numbers. Hence it's not a coreutils bug; it's a bug in your kernel or drivers or something like that. Most likely the other bugs are similar. Those "9000000" values all look very suspicious.
ok, works as designed: http://sourceforge.net/tracker/index.php?func=detail&aid=1311177&group_id=26275&atid=386747
