Fix statfs.Bsize on Darwin

[bolshevik]

Fixed mapping in FromStatfsT for Darwin, previously it resulted into incorrect reporting of total and free space in the "df" and "du" commands

#275 was fixing incorrectly showing free and available space based on block count. But this number also affects statistics reported by du. Better is to map both to Bsize and then all calculations are correct and there is no need to recalculate block count on the device.

https://opensource.apple.com/source/file_cmds/file_cmds-272.250.1/du/du.c.auto.html
howmany(p->fts_statp->st_blocks, blocksize)

And according to http://man7.org/linux/man-pages/man2/stat.2.html
blkcnt_t st_blocks; /* Number of 512B blocks allocated */

Which creates a mismatch.

Currently:

ls -l
total 4096
-rw-r--r--  1 x  x  1024 *** test
-rw-r--r--  1 x  x     0 *** test2
-rw-r--r--  1 x  x     2 *** test3

du *
2048	test
0	test2
2048	test3

So it thinks, that the file occupies 1 MB or 2048 512B blocks.

After the change:

ls -l
total 4096
-rw-r--r--  1 x  x  1024 *** test
-rw-r--r--  1 x  x     0 *** test2
-rw-r--r--  1 x  x     2 *** test3

du *
8	test
0	test2
8	test3

or 4K each.

It is also a follow up for #213

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[hanwen]

I need a CLA to take your contribution.

[bolshevik]

@googlebot I signed it!

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[bolshevik]

Thanks for the hint, I do not really want to assign my e-mail address to the commits... I signed the agreement and I am authoring these changes so I am fully fine and grant rights to accept this change and use it in future without any limitations. Thank you for this project!

[hanwen]

could you write a test for the du case ?

Write a file (let's 10240 bytes), syscall.Stat it through FUSE, and then verify that st_blocks is 20 (If I understand correctly).

[bolshevik]

@hanwen Thank you for the suggestion, sure I can try to correctly test it. But need to better learn the context. Will be keeping this PR updated with new contributions.