lkml.org 
[lkml]   [2004]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: nfs and LBD support (2TB+)
From
Date
to den 02.12.2004 Klokka 00:20 (+0100) skreiv Stephan van Hienen:
> Hi,
>
> i don't know if this is kernel related ?
>
> server is exporting nfs 2.3TB
>
> /dev/md0 2.3T 959G 1.4T 41% /raid
>
> on the client i see this as 316GB :
>
> storage:/raid 316GB 129GB 187GB 41% /raid
>
> server is running 2.6.10-rc2
> client is running 2.6.9-ac11
>
> both have LBD support enabled
> (and both are running tao (which is based on rhel 3))
>
> any ideas ?

Yep... There is a slight problem with the way glibc has decided to
implement the statvfs function when interacting with 2.6.x kernels...

The POSIX definition of statvfs declares that the entry f_blocks (which
returns the size of the filesystem) shall be in units of f_frsize (see
the manpage).

OTOH the system call sys_statfs() still returns f_blocks in units of
f_bsize (as it has done since the dawn of Linux)...

So when glibc calls sys_statfs(), and then just copies the results into
the statvfs format structure, it is putting a value of f_blocks which is
in units of f_bsize into something that should be in units of f_frsize.

This was not a problem in Linux-2.4.x, 'cos glibc would simply emulate a
value for f_frsize by setting it to f_bsize.
However for 2.6.x kernels, glibc grabs a value of f_frsize that the
kernel gives it. So if that value differs from the bsize (and allowing
f_frsize != f_bsize is the whole point of passing a value for f_frsize
to glibc in the first place), you get wierd discrepancies like the
above.

Cheers,
Trond

--
Trond Myklebust <trond.myklebust@fys.uio.no>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.457 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site