[Aboriginal] uClibc-0.9.33.2 statfs() does not populate the `f_frsize' field of `struct statfs'

Rob Landley rob at landley.net
Thu Dec 27 20:07:34 PST 2012


On 12/27/2012 03:03:32 PM, Rajeev V. Pillai wrote:
> > From: Rob Landley <rob at landley.net>
> >
> > On which architecture?
> >
> 
> ARM Tegra 2 tablet (armv7-a) running Android 2.3.5.
> 
> 
> > Right, I can copy one more field in this pointless data marshalling  
> wrapper.
> > (Long-term: migrating to musl.) In the meantime, something like the  
> attached?
> >
> Yeah. Either that or zero it out as the statfs() manpage says should  
> be done.
> BTW, musl has a similar data marshalling wrapper.
> 
> 
> > (What's your use case, by the way? What package did this break?)
> >
> None, except my version of df(1) which I wrote to test my own  
> *mntent() functions
> (missing in Android's Bionic libc).
> 
> I wanted to use the POSIX statvfs(3) whose man page states that the  
> various
> block-related statistics were in units of `f_frsize' rather than  
> `f_bsize'. But,
> since Android's Bionic doesn't have statvfs(3), but, has statfs(2), I  
> decided to
> go with that latter. However, my manpage of statfs(2) doesn't make  
> clear
> whether the units reported are by statfs() are in `f_frsize' or  
> `f_bsize'. I decided
> to go with `f_frsize' given that `f_bsize' is officially the  
> ``optimal transfer block size''.
> 
> I noticed that both busybox and toybox use `f_bsize', however--which  
> doesn't
> make much difference on most (ie. all those not implementing block  
> fragments)
> filesystems, though.

Are there any that implement it? Linus said he wanted to see fragments  
go away in 1995:

   http://lkml.indiana.edu/hypermail/linux/kernel/9507/0195.html

According to http://www.tldp.org/HOWTO/Partition/appendix.html in ext2,  
fragment size is hardwired to be equal to block size. So the fact  
nobody's noticed a field that was deprecated back around Linux 1.2  
isn't hooked up in the entire history of uClibc isn't hugely surprising.

Rob
 1356667654.0


More information about the Aboriginal mailing list