-
Notifications
You must be signed in to change notification settings - Fork 335
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stat: block size differences #41
Comments
This stackoverflow post indicates that the stat %B parameter for block size should be ignored as it may not necessarily reflect the actual file system block size value but usually some unrelated OS value. This would explain the values of 4096 which leads to huge discrepancies between allocated and actual file size (it's not a sparse file). What would be interesting though why busybox still gets the correct 512 blocksize value. Is it planned to support something like |
After more research, I think I got it now, see here. So the allocated file size on the filesystem is always calculated as block-count * 512 byte, with the result being in increments of the actual file system block size, which is the So why does busybox print the "correct" value of 512 for "Bytes per Block" which should usually just be ignored? Well it's hardcoded. Toybox returns the same value of @landley |
On 08/11/2016 03:49 AM, Matthias Urhahn wrote:
In toybox, both %o and %B come from the stat() system call. else if (type == 'B') out('u', stat->st_blksize); } else if (type == 'o') out('u', stat->st_blksize); I.E. we're telling you what the operating system told us (presumably A quick check shows busybox is printing a hardwired value for %B but the
I don't understand the point of printing a hardwired value for %B? FAT A few years ago hard drives went from 512 byte physical block to 4k, https://lwn.net/Articles/322777/ And now the sectors are getting bigger: https://lwn.net/Articles/582862/ Here's some articles about the damage conflicting block size assumptions https://lwn.net/Articles/349970/ You shouldn't have to care about 90% of that (the OS handles it all for
Busybox is returning a single hardwired answer. That said, it looks like the Ubuntu version is also doing that. If %B %B prints "512"
More stat fields: %b is st_blocks and %s is st_size. The stat(2) man page says that st_blocks is "number of 512B blocks %B units for %b (always 512)
The "man 1 stat" page says:
The "man 2 stat" page says:
So yes, you've found an inconsistency and I should fix it. %B should Thanks. Good catch, Rob |
Fixed with 4460e9f 👍 Thanks! |
Toybox 0.7.1, Busybox 1.24.2
On a Nexus5@6.0.
Why is there a difference in blocksize?
busybox says 512Byte while toybox says 4096Byte.
28632 Blocks * 512Byte = 14659584 Byte
Which is a lot closer to the actual file size of 14657536 Byte (reported by both toybox&busybox).
Other commands from both binaries also show a block size of 4096 Byte though.
The text was updated successfully, but these errors were encountered: