@josharian and I see this on both 10.8 and 10.10, both on VMWare. I think VMWare is not really at fault, but now we're just getting a different number of mounted filesystems and finally seeing the mistake.

I suspect our syscall.Statfs_t struct is the wrong size or layout and the kernel is only giving us 4 filesystems worth of data because we're telling it a smaller bufsize than it's expecting.

/cc @ianlancetaylor

CL https://golang.org/cl/28487 mentions this issue.

What is the output of the mount command run with no arguments?

Good question. I'll add more debugging.

I tried checking the C-vs-Go size, but the Go struct is at least how bug cgo thinks it is (C.sizeof_struct_etc), which makes sense since Go made the struct.

The failure after adding more debugging is:

--- FAIL: TestGetfsstat (0.00s)
    syscall_bsd_test.go:18: Getfsstat(nil, MNT_WAIT) = (5, <nil>)
    syscall_bsd_test.go:25: Getfsstat([]syscall.Statfs_t, MNT_WAIT) = (4, <nil>)
    syscall_bsd_test.go:33: index 4 is an empty Statfs_t struct
FAIL
FAIL    syscall 0.147s

I'll make it also log the mount output, and the contents of the non-zero struct entries.

CL https://golang.org/cl/28550 mentions this issue.

@quentinmit raised a good point on https://golang.org/cl/28550 .... how does OS X's mount itself work?

dtruss says:

Notably, it's passing a buffer size of 0x32d0, which is one element bigger than it needs to:

bradfitz@laptop ~$ cat size.go
package main

import (
    "syscall"
    "unsafe"
)

func main() {
    println(unsafe.Sizeof(syscall.Statfs_t{}))
}

bradfitz@laptop ~$ go run size.go
2168

bradfitz@laptop ~$ python
Python 2.7.10 (default, Oct 23 2015, 19:19:21) 
[GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 0x32d0 / 2168
6

I suppose we could just do that too.

OS X mount,
http://opensource.apple.com/source/diskdev_cmds/diskdev_cmds-582/mount.tproj/mount.c

... calls getmntinfo:

https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man3/getmntinfo.3.html

And its source:

https://opensource.apple.com/source/Libc/Libc-167/gen.subproj/getmntinfo.c

int
getmntinfo(mntbufp, flags)
    struct statfs **mntbufp;
    int flags;
{
    static struct statfs *mntbuf;
    static int mntsize;
    static long bufsize;

    if (mntsize <= 0 && (mntsize = getfsstat(0, 0, MNT_NOWAIT)) < 0)
        return (0);
    if (bufsize > 0 && (mntsize = getfsstat(mntbuf, bufsize, flags)) < 0)
        return (0);
    while (bufsize <= mntsize * sizeof(struct statfs)) {
        if (mntbuf)
            free(mntbuf);
        bufsize = (mntsize + 1) * sizeof(struct statfs);
        if ((mntbuf = (struct statfs *)malloc(bufsize)) == 0)
            return (0);
        if ((mntsize = getfsstat(mntbuf, bufsize, flags)) < 0)
            return (0);
    }
    *mntbufp = mntbuf;
    return (mntsize);
}

Notably:

        bufsize = (mntsize + 1) * sizeof(struct statfs);

No, the size doesn't matter at all.

Tested it on a VMware instance. MNT_NOWAIT (2) works, which is what mount does. MNT_WAIT (1) doesn't work.

CL https://golang.org/cl/28585 mentions this issue.

This happened again yesterday:

https://storage.googleapis.com/go-build-log/326d8dd1/darwin-amd64-10_11_c1295122.log

@ALTree, only because it was a trybot run on an old commit which hadn't been rebased to tip and didn't have the updated test.

Ah! Thanks and sorry for the noise. I will rebase my CL.