bug#7355: coreutils df on OSX reports wrong sizes for large filesystems

[Tim Spriggs]

2010/11/8 Pádraig Brady <address@hidden>:
> On 08/11/10 23:38, Tim Spriggs wrote:
>> 2010/11/8 Pádraig Brady <address@hidden>:
>>> On 08/11/10 20:37, Tim Spriggs wrote:
>>>> Hello,
>>>>
>>>>   I am running gentoo-prefix on OSX which builds coreutils. When I
>>>> compare the output of the system df to the standard GNU df I get:
>>>>
>>>>
>>>> $ /bin/df -h /data/hirise06
>>>> Filesystem               Size   Used  Avail Capacity  Mounted on
>>>> hiserve2:/vol/hirise06  7.9Ti  430Gi  7.5Ti     6%    /data/hirise06
>>>>
>>>> $ df -h /data/hirise06
>>>> Filesystem            Size  Used Avail Use% Mounted on
>>>> hiserve2:/vol/hirise06
>>>>                       2.0T  431G -523G   -  /data/hirise06
>>>>
>>>> The 2.0T size looks suspicious to me. Maybe an integer is overflowing 
>>>> somewhere?
>>>
>>> Well 2T is between 32 bit and 64 bit.
>>> If I had to guess I'd say df was using a 32 bit statfs
>>> that was returning 1024 blksize?
>>>
>>> Could you compare the system calls made by both versions of df.
>>> On GNU/Linux I can trace the statfs calls like:
>>>
>>> strace -v -e statfs,statfs64 df /data/hirise06
>>>
>>> If the trace for the above gives no output
>>> for either command, then can you include the
>>> full trace output.
>>>
>>> thanks,
>>> Pádraig.
>>>
>>
>
> It does look like the right functions are being called.
> If you could concentrate on the calls below
> (with the dtruss -t option according to google),
> you might notice some differences.
>
>> # dtruss -c -f /opt/prefix/bin/df /data/hirise06
>>
>>
>> CALL                                        COUNT
>> fstatfs64                                       1
>> statfs64                                        1
>> getfsstat64                                     2
>>
>> and similarly:
>>
>> # dtruss -c -f /bin/df /data/hirise06
>>
>> CALL                                        COUNT
>> statfs64                                        1
>> getfsstat64                                     2
>
> Without an OSX box to work on, it's awkward.
>
> cheers,
> Pádraig.
>

Thanks for your patience. If this gets too much further I may just
make an OSX box available to you if you want. I had to modify the
dtruss command to dtruss.stats in order to grab all the syscalls into
one output. Otherwise you can only specify one call with -t afaict.
:-/ Anyway, with stack information included:

guru ~ # ./dtruss.stats -s -t fstatfs64,statfs64,getfsstat64 -f
/bin/df -h /data/hirise07
Filesystem               Size   Used  Avail Capacity  Mounted on
hiserve1:/vol/hirise07  4.5Ti  3.4Ti  1.1Ti    77%    /data/hirise07
        PID/THRD  SYSCALL(args)                  = return
  754/0x296efe:  getfsstat64(0x0, 0x0, 0x2)              = 11 0

              libSystem.B.dylib`getfsstat64+0xa
              df`0x100002505
              df`0x1000015c4
              df`0x3

  754/0x296efe:  getfsstat64(0x100800000, 0x65A0, 0x2)           = 11 0

              libSystem.B.dylib`getfsstat64+0xa
              df`0x100002505
              df`0x1000015c4
              df`0x3

  754/0x296efe:  statfs64(0x7FFF5FBFEA83, 0x7FFF5FBFE070, 0x0)           = 0 0

              libSystem.B.dylib`statfs$INODE64+0xa
              df`0x1000015c4
              df`0x3

guru ~ # ./dtruss.stats -s -t fstatfs64,statfs64,getfsstat64 -f
/opt/prefix/bin/df -h /data/hirise07
Filesystem            Size  Used Avail Use% Mounted on
hiserve1:/vol/hirise07
                      512G -591G -946G  39% /data/hirise07
        PID/THRD  SYSCALL(args)                  = return
  762/0x296f30:  fstatfs64(0x3, 0x7FFF5FBFA850, 0x0)             = 0 0

              libSystem.B.dylib`fstatfs64+0xa
              CoreFoundation`_CFBundleCopyDirectoryContentsAtPath+0x63f
              CoreFoundation`_CFBundleURLLooksLikeBundleVersion+0x41
              CoreFoundation`_CFBundleCreate+0x14d
              CoreFoundation`_CFBundleGetMainBundleAlreadyLocked+0xad
              CoreFoundation`CFBundleGetMainBundle+0x69
              CoreFoundation`cacheBundleInfo+0xc
              CoreFoundation`_CFAppVersionCheckLessThan+0x90
              CoreFoundation`__CFInitialize+0x6a6
              dyld`ImageLoaderMachO::doImageInit(ImageLoader::LinkContext
const&)+0x8a
              dyld`ImageLoaderMachO::doInitialization(ImageLoader::LinkContext
const&)+0x1b
              dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext
const&, unsigned int)+0xec
              dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext
const&, unsigned int)+0x9d
              dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext
const&, unsigned int)+0x9d
              dyld`ImageLoader::runInitializers(ImageLoader::LinkContext
const&)+0x3a
              dyld`dyld::initializeMainExecutable()+0x85
              dyld`dyld::_main(macho_header const*, unsigned long,
int, char const**, char const**, char const**)+0xbb1
              dyld`dyldbootstrap::start(macho_header const*, int, char
const**, long)+0x31f
              dyld`_dyld_start+0x2a
              df`0x100000000

  762/0x296f30:  getfsstat64(0x0, 0x0, 0x2)              = 11 0

              libSystem.B.dylib`getfsstat64+0xa
              df`read_file_system_list+0x1f
              df`main+0x578
              df`start+0x34
              df`0x3

  762/0x296f30:  getfsstat64(0x101010C00, 0x65A0, 0x2)           = 11 0

              libSystem.B.dylib`getfsstat64+0xa
              df`read_file_system_list+0x1f
              df`main+0x578
              df`start+0x34
              df`0x3

  762/0x296f30:  statfs64(0x7FFF5FBFEA5E, 0x7FFF5FBFD980,
0x7FFF5FBFE610)          = 0 0

              libSystem.B.dylib`statfs$INODE64+0xa
              df`get_fs_usage+0x15
              df`show_dev+0xad2
              df`main+0x9b0
              df`start+0x34
              df`0x3

Thanks,
-Tim