Export to GitHub

xmobar - issue #70

StatFS.hsc returns wrong values on linux s390


Posted on Jan 14, 2012 by Helpful Dog

As I've mentioned before, I'm using StatFS.hsc in git-annex. I noticed it was failing on several of Debian's architectures: s390, mips, powerpc, sparc. (I'm only investigated in detail on s390, but this bug probably affects all of those. OTOH, related architectures like s390x and mipsel don't seem to have the bug.)

main = print =<< getFileSystemStats "."

Just (FileSystemStats {fsStatBlockSize = 4096, fsStatBlockCount = 0, fsStatByteCount = 0, fsStatBytesFree = 0, fsStatBytesAvailable = 0, fsStatBytesUsed = 0})

Notice all 0 except the blocksize. My guess is that fsblkcnt_t perhaps varies on these architectures (although I can't see how), or that statfs64 returns a different structure than expected there.

I tried changing it to call statfs instead, but that resulted in nonzero but wrong values. (For example fsStatBytesAvailable > fsStatBytesFree) Same values I get if I make it call statvfs and use struct statvfs.

Comment #1

Posted on Jan 14, 2012 by Quick Kangaroo

Sounds a lot like a endianness problem if you ask me.

Especially after looking into StatFS.hsc and seeing that the blocksize is the only value not being converted from CLong to Integer.

Comment #2

Posted on Jan 17, 2012 by Helpful Dog

All the failing arches are big endian, indeed.

So is s390x, where it seemed to work, but perhaps it just produced differently bad data. After all, the only difference between debian's s390 and s390x is the latter has a 64 bit userland. Will check.

Comment #3

Posted on Jan 18, 2012 by Helpful Dog

s390x indeed has different but clearly wrong data:

Just (FileSystemStats {fsStatBlockSize = 17592186044416, fsStatBlockCount = 11546880, fsStatByteCount = 203134861192546222080, fsStatBytesFree = 63484781040995663872, fsStatBytesAvailable = 53167755574317678592, fsStatBytesUsed = 139650080151550558208})

The blocksize does actually go through toI as well. Strange it's only wrong on s390x.

Still, this does seem an endianness problem. Question is, is it a ghc bug, in handling the big endian CLong wrong, or is StatFS supposed to handle that when unpacking the struct?

Comment #4

Posted on Feb 2, 2013 by Swift Wombat

A couple of months ago i fixed a problem we had in this module with the statfs function that was called, which was giving wrong values also in my system and actually making the process to eventually segfault. Althought that only started happening in very recent kernels, perhaps it makes a difference for s390x too...

Status: New

Labels:
Type-Defect Priority-Medium