Rein Klazes wijn@wanadoo.nl writes:
Totals size of the file system should be f_blocks * f_frsize, but that gives a value 16 times too small. In this case f_blocks (as f_bfree, f_bavail) are the number of f_bsize blocks, wrong. This is a quite up-to-date system, Debian unstable with 2.6.10 kernel.
Attached is the simplest solution, fall back to fstatfs() on Linux systems. It is btw also what 'df' does.
Wouldn't it be easier to simply use f_bsize instead of f_frsize? Why would switching to fstatfs be preferable?
On 05 Jan 2005 18:29:47 +0100, you wrote:
Rein Klazes wijn@wanadoo.nl writes:
Totals size of the file system should be f_blocks * f_frsize, but that gives a value 16 times too small. In this case f_blocks (as f_bfree, f_bavail) are the number of f_bsize blocks, wrong. This is a quite up-to-date system, Debian unstable with 2.6.10 kernel.
Attached is the simplest solution, fall back to fstatfs() on Linux systems. It is btw also what 'df' does.
Wouldn't it be easier to simply use f_bsize instead of f_frsize? Why would switching to fstatfs be preferable?
Because as soon as fstatvfs is fixed (for some combination of kernel/filesystem/libc), you are wrong again. The f_blocks, f_bfree and other fields are supposed to be counted as f_frsize sized blocks. And at least for nfs, f_frsize does not always equal f_bsize.
So if you use fstatvfs, you must use f_frsize. If that is broken you must revert to fstatfs.
Rein.
Rein Klazes wijn@wanadoo.nl writes:
Because as soon as fstatvfs is fixed (for some combination of kernel/filesystem/libc), you are wrong again. The f_blocks, f_bfree and other fields are supposed to be counted as f_frsize sized blocks. And at least for nfs, f_frsize does not always equal f_bsize.
Ah I see your point, yes I suppose glibc could try to do the clever thing and scale the returned values according to f_frsize. So yes I guess we have to give up on fstatvfs, too bad.
-
Alexandre Julliard -
Rein Klazes