Test statfs_call() fails on macOS because statfs() and statvfs() report different number of i-nodes

[SteveLauC]

Sometimes, test statfs_call() fails in our macOS CI, e.g., this one:

failures:

---- sys::test_statfs::statfs_call stdout ----
thread 'sys::test_statfs::statfs_call' panicked at 'assertion failed: `(left == right)`
  left: `1609964262`,
 right: `1609964300`', test/sys/test_statfs.rs:47:5

It failed in this line, where statfs() and statvfs() were reporting different number of i-nodes.

[asomers]

That's weird. That line checks the total number of inodes on the file system. That should never change, at least on a traditional file system like UFS. But apparently it can change here. I wonder if it was /dev or one of the real file systems?

[SteveLauC]

That test checks 4 paths, according to the output of mount on my mac, they refer to:

#[test]
fn statfs_call() {
    check_statfs("/tmp"); // refers to the file system mounted at `/`
    check_statfs("/dev"); // refers to the file system mounted at `/dev`
    check_statfs("/run"); // will be skipped since this directory does not exist
    check_statfs("/");    // refers to the file system mounted at `/`
}

I wonder if it was /dev or one of the real file systems?

So yes, it indeed checks /dev though I am not sure if it is the one that is causing the failure since they all run in 1 test.

[asomers]

I think we should just remove the check for number of inodes. After all, our goal isn't to test statvfs itself, just to test that our bindings to it are doing the right thing.

[SteveLauC]

I think we should just remove the check for number of inodes. After all, our goal isn't to test statvfs itself, just to test that our bindings to it are doing the right thing.

Yeah, let me remove it.