GNU bug report logs - #9140
[du] broken on OSX 10.7 (Lion) for >4TB file systems

Previous Next

Full log

Message #11 received at 9140 <at> debbugs.gnu.org (full text, mbox):

From: Herb Wartens <hawartens <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 9140 <at> debbugs.gnu.org
Subject: Re: bug#9140: Coreutils Bug on OSX 10.7 (Lion)
Date: Thu, 21 Jul 2011 16:35:52 -0700

[Message part 1 (text/plain, inline)]

On Thu, Jul 21, 2011 at 2:39 PM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:

> > On OSX 10.7 the relevant fields of the statvfs structure
> > are defined to be fsblkcnt_t, or only 4 bytes long.
>
> Thanks for the bug report.  Could you please give more details about
> the problem?  What is the size of your file system?  What are the
> types (e.g., are the types signed? and what are their sizes?)
> and values of f_frsize, f_bsize, f_blocks, and all the other
> members of a struct statvfs?
>
>
Sure.  The filesystem is 5.5TiB (5,858,217,984 bytes).  This is beyond the
capacity an unsigned int can hold.  Here is an example of the bug:
> df /Volumes/VIDEO
Filesystem                         1K-blocks        Used   Available Use%
Mounted on
//user1 <at> 192.168.1.100/VIDEO <http://hawartens <at> 192.168.101.151/VIDEO>
 1563250688 -1474553224 -1257163384  54% /Volumes/VIDEO

Here is what it should look like:
> df /Volumes/VIDEO
Filesystem                         1K-blocks       Used  Available Use%
Mounted on
//user1 <at> 192.168.1.100/VIDEO <http://hawartens <at> 192.168.101.151/VIDEO>
 5858217984 2820414072 3037803912  49% /Volumes/VIDEO


Here are the relevant definitions on OSX:
struct statvfs {
    unsigned long f_bsize;    /* File system block size */
    unsigned long f_frsize;   /* Fundamental file system block size */
    fsblkcnt_t    f_blocks;   /* Blocks on FS in units of f_frsize */
    fsblkcnt_t    f_bfree;    /* Free blocks */
    fsblkcnt_t    f_bavail;   /* Blocks available to non-root */
    fsfilcnt_t    f_files;    /* Total inodes */
    fsfilcnt_t    f_ffree;    /* Free inodes */
    fsfilcnt_t    f_favail;   /* Free inodes for non-root */
    unsigned long f_fsid;     /* Filesystem ID */
    unsigned long f_flag;     /* Bit mask of values */
    unsigned long f_namemax;  /* Max file name length */
};

typedef __darwin_fsblkcnt_t fsblkcnt_t;
typedef __darwin_fsfilcnt_t fsfilcnt_t;

typedef unsigned int __darwin_fsblkcnt_t; /* Used by statvfs and fstatvfs */
typedef unsigned int __darwin_fsfilcnt_t; /* Used by statvfs and fstatvfs */

(gdb) print sizeof(buf.f_bsize)
$2 = 8
(gdb) print sizeof(buf.f_frsize)
$3 = 8
(gdb) print sizeof(buf.f_blocks)
$4 = 4
(gdb) print sizeof(buf.f_bfree)
$5 = 4
(gdb) print sizeof(buf.f_bavail)
$6 = 4
(gdb) print sizeof(buf.f_files)
$7 = 4
(gdb) print sizeof(buf.f_ffree)
$8 = 4
(gdb) print sizeof(buf.f_favail)
$9 = 4
(gdb) print sizeof(buf.f_fsid)
$10 = 8
(gdb) print sizeof(buf.f_flag)
$11 = 8
(gdb) print sizeof(buf.f_namemax)
$12 = 8



> The patch you sent essentially says "statvfs is broken so badly on
> MacOS X 10.7 that nobody should ever use it".  Is that really right?
> It sounds extreme.
>
>
Not saying no one should use it at all.  All I am saying is that when using
really large filesystems, then the statvfs structure is insufficient on OSX.
 Hope this helps.

-Herb

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.