On Jan 10, 2006, at 9:48 AM, Rob Ross wrote:
Good catch Justin, nice searching Murali, and good explanation of
the fields Sam. Looks like this is someone else's problem, but
something that we can fix.
Let's just assign buf->f_frsize = sb->s_blocksize as you guys
suggest. It appears that we will then need to also adjust f_ffree?
Then we wait and see what code breaks because it assumes f_frsize
is 1K :).
Well I've committed it so now we just have to wait for the bug
report. :-)
-sam
Thanks everyone,
Rob
Murali Vilayannur wrote:
Hi Justin,
Perhaps this explains why nautilus and a few other gnome apps have
this
issue,
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140744
It is probably a libgnome/libc(statvfs?) bug, I don't know (both
nautilus
and df make the exact same call to statfs64 and perform different
calculations
to compute the available disk-space)
I see the following comments in nfs statfs code,
/*
* Current versions of glibc do not correctly handle the
* case where f_frsize != f_bsize. Eventually we want to
* report the value of wtmult in this field.
*/
buf->f_frsize = sb->s_blocksize;
/*
* On most *nix systems, f_blocks, f_bfree, and f_bavail
* are reported in units of f_frsize. Linux hasn't had
* an f_frsize field in its statfs struct until recently,
* thus historically Linux's sys_statfs reports these
* fields in units of f_bsize.
*/
buf->f_bsize = sb->s_blocksize;
So perhaps, we should also do the same in super.c by setting
buf->f_frsize to sb->s_blocksize similar to what you are doing in
your
patch to workaround this..
Thanks,
Murali
On Tue, 10 Jan 2006, Justin Mazzola Paluska wrote:
On Tue, Jan 10, 2006 at 01:41:29AM -0600, Sam Lang wrote:
(using strace, the system call that Python's os.statvfs
actually makes
is:
statfs64("/RAIDS/RAID_2", 84, {f_type=0x20030528,
f_bsize=4194304,
f_blocks=1001258, f_bfree=705068, f_bavail=705068,
f_files=4294967292,
f_ffree=4294967277, f_fsid={2016975803, 0}, f_namelen=255,
f_frsize=1024}) = 0
)
705,068 1KB blocks would give me the 688MB free.
But that's using f_frsize as the block size, which is actually the
fragment size. If you use f_bsize as the block size, the f_bavail
looks correct. For the 2.4 kernel, we just set f_frsize to 1024,
which is why you're seeing those results. It looks like the 2.6
kernel doesn't have the f_frsize field in the statfs struct, so
you'll probably have more luck if you're able to update to the 2.6
I should have said, but this result is from a system running a 2.6
kernel and kernel module. 2.6.14 to be exact.
Looking at src/kernel/linux-2.6/super.c:370 it looks like the
f_frsize
is set to 1024 by default in the 2.6 kernel too.
Applying the attached patch sets f_frsize to f_bsize and fixes my
problems in Nautilus. However, is this a kosher thing to do? I
don't
know much about kernel data structures. Turning this question
around,
is there a specific reason why f_frsize is set to 1024?
kernel. I'm curious why Nautilus and other tools use don't use the
f_bsize field (seems like a bug)...if you're able to strace the
Nautilus process that might be enlightening.
I've attached a bzip2 of an strace of nautilus cut down to the 2
second snippet where I'm accessing the PVFS2 mountpoint
(/RAIDS/RAID_2). This is using the kernel module without the patch
from above. The expanded file is about 310K. However, it looks
like
it makes the same statfs64 call with the same return values.
--Justin
_______________________________________________
PVFS2-users mailing list
PVFS2-users@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-users
_______________________________________________
PVFS2-users mailing list
PVFS2-users@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-users
