Re: nfs and LBD support (2TB+)

[Trond Myklebust]

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@xxxxxxxxxx>

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