stat reports wrong fundamental block size

Bug #412069 reported by Nikolaus Rath
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
coreutils (Ubuntu)
New
Low
Unassigned

Bug Description

Binary package hint: coreutils

$ strace -e statfs64 stat -f tmp/hello
statfs64("/selinux", 84, {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=2999602, f_bfree=1248019, f_bavail=1095663, f_files=761856, f_ffree=544311, f_fsid={1229872637, -1185844299}, f_namelen=255, f_frsize=4096}) = 0
statfs64("tmp/hello", 84, {f_type=0x65735546, f_bsize=1024, f_blocks=4, f_bfree=0, f_bavail=0, f_files=1, f_ffree=0, f_fsid={0, 0}, f_namelen=0, f_frsize=512}) = 0
  File: "tmp/hello"
    ID: 0 Namelen: 0 Type: UNKNOWN (0x65735546)
Block size: 1024 Fundamental block size: 1024
Blocks: Total: 4 Free: 0 Available: 0
Inodes: Total: 1 Free: 0

Note that statfs64 returns 512, but stat prints 1024.

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
Package: coreutils 6.10-6ubuntu1
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: coreutils
Uname: Linux 2.6.28-14-generic i686

Revision history for this message
Nikolaus Rath (nikratio) wrote :
Revision history for this message
Nikolaus Rath (nikratio) wrote :

From http://thread.gmane.org/gmane.comp.file-systems.fuse.devel/8042/focus=8052

The problem is this in stat.c:

/* Keep this conditional in sync with the similar conditional in
    ../m4/stat-prog.m4. */
#if (STAT_STATVFS \
&& (HAVE_STRUCT_STATVFS_F_BASETYPE || HAVE_STRUCT_STATVFS_F_FSTYPENAME \
      || (! HAVE_STRUCT_STATFS_F_FSTYPENAME && HAVE_STRUCT_STATVFS_F_TYPE)))
# define USE_STATVFS 1
#else
# define USE_STATVFS 0
#endif

It hasn't been kept in sync so USE_STATVFS is zero and so the f_frsize
field isn't used at all. I'm not sure what that conditional should be,
but none of those symbols are defined -- there's something wrong with
the configure script that I haven't looked into.

Changed in coreutils (Ubuntu):
status: New → Confirmed
Revision history for this message
Jim Meyering (meyering) wrote :

As far as I can see, there is no problem with code being out of sync.
If you can point to specifics, please let me know,
since I'm about to release coreutils-7.5 upstream.

However, note that with glibc and a linux kernel, the stat program
always uses statfs, and not statvfs. This is a deliberate decision
taken at configure time. Details in comments here:

    http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/fsusage.m4#n50

However, the version of statvfs that forced us into this corner
dates back to 2003:

    http://git.sv.gnu.org/cgit/gnulib.git/commit/?id=eda39b870b7a849271

If someone does the legwork to determine whether that statvfs bug has been
fixed, and if so, since when, we should be able to write a configure test
to use glibc's statvfs when it's known not to be buggy.

Revision history for this message
C de-Avillez (hggdh2) wrote :

@Nikolaus: thank you for opening this bug and helping make Ubuntu better. In the future, please do not confirm your own bugs -- please see https://wiki.ubuntu.com/Bugs/Status for a quick explanation of bug stati.

@Jim: thank you for your quick response, it is appreciated. Given time, I will try to check on it.

Meanwhile: changing to Incomplete: this is, right now, the Right Way To Do It (tm), unless we can show statvfs now works, er, correctly.

Changed in coreutils (Ubuntu):
importance: Undecided → Low
status: Confirmed → Incomplete
Revision history for this message
Nikolaus Rath (nikratio) wrote :

@hggdh: I marked it as confirmed because it has been reproduced by other people who reported their findings on the link I provided.

I have written a short test program that just calls statvfs on a mountpoint and a FUSE filesystem that just hangs for 10 seconds when statvfs is called. According to my tests, the statvfs bug has been fixed:

$ ./hang_on_statvfs tmp/ # this fs will hang for 10 seconds on statvfs()
$ ./hello tmp2/ # this one won't
$ $ time ./stattest / # stattest just calls statvfs
Running statvfs('/')

real 0m0.002s
user 0m0.000s
sys 0m0.004s

$ time ./stattest tmp2/hello
Running statvfs('tmp2/hello')

real 0m0.002s
user 0m0.004s
sys 0m0.000s

$ time ./stattest tmp/hello
Running statvfs('tmp/hello')

real 0m10.002s
user 0m0.000s
sys 0m0.004s

I don't feel confident enough to replace my libc with older versions though to test since when this has been fixed.

Revision history for this message
Nikolaus Rath (nikratio) wrote :
Changed in coreutils (Ubuntu):
status: Incomplete → New
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.