Discussion:
Stat, wrong blockcount for F2FS filesystems?
(too old to reply)
darken
2017-04-07 16:10:47 UTC
Permalink
Raw Message
I'm using stat to display filesize and allocated size in my Android app.

I calculate the allocated size by multiplying the block count (%b) with 512
Byte.

I found out in https://github.com/landley/toybox/issues/41 that the
blocksize for the blockcount calculation is hardcoded to 512. So this
should work well (and has so far).

Now a user of my app noticed that on their F2FS filesystem the allocated
size is suspiciously small:
https://github.com/d4rken/sdmaid-public/issues/830

Specifically too small by a factor of 8, as if the blocksize used for
blockcount calculation is 4096 (4096/512).

Could stat have a problem with calculating the blockcount on F2FS
filesystems or am I overlooking something else?

~Matthias
darken
2017-04-07 18:31:30 UTC
Permalink
Raw Message
Wrong train of thought, toybox stat doesn't do any blockcount calculation,
but just gets the value from `st_blocks`.

We are getting bad values from `/storage/emulated/0` which is FUSE mounted
from `/data/media/0` and the blockcount values from `/data/media/0` are
sane.

So this seems to be FUSE related...

~Matthias
Post by darken
I'm using stat to display filesize and allocated size in my Android app.
I calculate the allocated size by multiplying the block count (%b) with
512 Byte.
I found out in https://github.com/landley/toybox/issues/41 that the
blocksize for the blockcount calculation is hardcoded to 512. So this
should work well (and has so far).
Now a user of my app noticed that on their F2FS filesystem the allocated
https://github.com/d4rken/sdmaid-public/issues/830
Specifically too small by a factor of 8, as if the blocksize used for
blockcount calculation is 4096 (4096/512).
Could stat have a problem with calculating the blockcount on F2FS
filesystems or am I overlooking something else?
~Matthias
enh
2017-04-08 01:55:36 UTC
Permalink
Raw Message
yeah, there was a stat bug that was fixed. some filesystems modify the
block value before passing it back. drosen fixed sdcardfs to look at this
in "ANDROID: sdcardfs: Get the blocksize from the lower fs":

int f2fs_getattr(struct vfsmount *mnt,
struct dentry *dentry, struct kstat *stat)
{
struct inode *inode = dentry->d_inode;
generic_fillattr(inode, stat);
stat->blocks <<= 3;
return 0;
}

so that's where the factor of 8 would come from.
Post by darken
Wrong train of thought, toybox stat doesn't do any blockcount calculation,
but just gets the value from `st_blocks`.
We are getting bad values from `/storage/emulated/0` which is FUSE mounted
from `/data/media/0` and the blockcount values from `/data/media/0` are
sane.
So this seems to be FUSE related...
~Matthias
Post by darken
I'm using stat to display filesize and allocated size in my Android app.
I calculate the allocated size by multiplying the block count (%b) with
512 Byte.
I found out in https://github.com/landley/toybox/issues/41 that the
blocksize for the blockcount calculation is hardcoded to 512. So this
should work well (and has so far).
Now a user of my app noticed that on their F2FS filesystem the allocated
https://github.com/d4rken/sdmaid-public/issues/830
Specifically too small by a factor of 8, as if the blocksize used for
blockcount calculation is 4096 (4096/512).
Could stat have a problem with calculating the blockcount on F2FS
filesystems or am I overlooking something else?
~Matthias
_______________________________________________
Toybox mailing list
http://lists.landley.net/listinfo.cgi/toybox-landley.net
--
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.
enh
2017-04-08 01:55:51 UTC
Permalink
Raw Message
thanks. replied on the list, s/i/drosen/ :-)
Post by enh
yeah, there was a stat bug that was fixed. some filesystems modify the
block value before passing it back. drosen fixed sdcardfs to look at this
int f2fs_getattr(struct vfsmount *mnt,
struct dentry *dentry, struct kstat *stat)
{
struct inode *inode = dentry->d_inode;
generic_fillattr(inode, stat);
stat->blocks <<= 3;
return 0;
}
so that's where the factor of 8 would come from.
Post by darken
Wrong train of thought, toybox stat doesn't do any blockcount
calculation, but just gets the value from `st_blocks`.
We are getting bad values from `/storage/emulated/0` which is FUSE
mounted from `/data/media/0` and the blockcount values from `/data/media/0`
are sane.
So this seems to be FUSE related...
~Matthias
Post by darken
I'm using stat to display filesize and allocated size in my Android app.
I calculate the allocated size by multiplying the block count (%b) with
512 Byte.
I found out in https://github.com/landley/toybox/issues/41 that the
blocksize for the blockcount calculation is hardcoded to 512. So this
should work well (and has so far).
Now a user of my app noticed that on their F2FS filesystem the allocated
https://github.com/d4rken/sdmaid-public/issues/830
Specifically too small by a factor of 8, as if the blocksize used for
blockcount calculation is 4096 (4096/512).
Could stat have a problem with calculating the blockcount on F2FS
filesystems or am I overlooking something else?
~Matthias
_______________________________________________
Toybox mailing list
http://lists.landley.net/listinfo.cgi/toybox-landley.net
--
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.
--
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.
darken
2017-04-08 10:09:16 UTC
Permalink
Raw Message
So `f2fs_getattr` expected a higher value that needed to be decreased by a
factor of 8, but the value is not fixed and in this case the value was
already correct and the `<<= 3` decreased by a factor of 8 anyways, leading
to the wrong blockcount value?

I guess there is not much I can do about this from my end. The affected
user is rooted though and could probably fix this by updating his kernel.

Thanks for the insight Elliott!
Post by enh
thanks. replied on the list, s/i/drosen/ :-)
Post by enh
yeah, there was a stat bug that was fixed. some filesystems modify the
block value before passing it back. drosen fixed sdcardfs to look at this
int f2fs_getattr(struct vfsmount *mnt,
struct dentry *dentry, struct kstat *stat)
{
struct inode *inode = dentry->d_inode;
generic_fillattr(inode, stat);
stat->blocks <<= 3;
return 0;
}
so that's where the factor of 8 would come from.
Post by darken
Wrong train of thought, toybox stat doesn't do any blockcount
calculation, but just gets the value from `st_blocks`.
We are getting bad values from `/storage/emulated/0` which is FUSE
mounted from `/data/media/0` and the blockcount values from `/data/media/0`
are sane.
So this seems to be FUSE related...
~Matthias
Post by darken
I'm using stat to display filesize and allocated size in my Android app.
I calculate the allocated size by multiplying the block count (%b) with
512 Byte.
I found out in https://github.com/landley/toybox/issues/41 that the
blocksize for the blockcount calculation is hardcoded to 512. So this
should work well (and has so far).
Now a user of my app noticed that on their F2FS filesystem the
https://github.com/d4rken/sdmaid-public/issues/830
Specifically too small by a factor of 8, as if the blocksize used for
blockcount calculation is 4096 (4096/512).
Could stat have a problem with calculating the blockcount on F2FS
filesystems or am I overlooking something else?
~Matthias
_______________________________________________
Toybox mailing list
http://lists.landley.net/listinfo.cgi/toybox-landley.net
--
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.
--
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.
Loading...