Messages in this thread | | | Subject | Re: nfs and LBD support (2TB+) | From | Trond Myklebust <> | Date | Wed, 01 Dec 2004 18:50:33 -0500 |
| |
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/
| |