I had a question regarding NFSv3 Client and server but was not sure who to
ask.
The NFSv3 RFC states that NFSv3 should support 8 byte FILEID's. Does Linux
support 8 byte FILEID's for NFSv3? It seems that most commands do support
the use of large FileID's but gcc seems to have a problem.
This is what I see in the RFC1813
File attribute changes from NFSv2.
The size and fileid fields have been widened to eight-byte unsigned
integers from four-byte integers.
On Fri, 2007-01-12 at 11:31 -0600, Christopher T Vogan wrote:
>
> I had a question regarding NFSv3 Client and server but was not sure
> who to ask.
> The NFSv3 RFC states that NFSv3 should support 8 byte FILEID's. Does
> Linux
> support 8 byte FILEID's for NFSv3? It seems that most commands do
> support the use of large FileID's but gcc seems to have a problem.
>
> This is what I see in the RFC1813
> File attribute changes from NFSv2.
> The size and fileid fields have been widened to eight-byte unsigned
> integers from four-byte integers.
We don't currently export 64-bit inode numbers to userland on 32-bit
platforms because the code to allow getdents64() and stat64() to deal
with them was only recently merged into the kernel (as of 2.6.19).
I believe that David Howells does have patches that allows NFS to make
use of this new functionality, but he hasn't asked me to push them to
Linus yet. I'm not sure why.
Cheers,
Trond
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Thanks Trond,
So does this mean that Linux on a 64bit system supports 8 byte FileID's
with NFSv3 now? Is there a time frame when these patches will be merged
into the mainstream kernel? I am more interested in the client as it is
connecting to ZFS file sytems on Sun. Snoop tracing showed the FileID was 8
bytes. but I got a message on the linux system "Value too large for
defined data type". Now this message was produced by the running program
but i expect that other user tools will have the same issue if they cannot
handle stat64 calls.
How can I get these patches from Dave?
Christopher Vogan
Dept. W98 NFS Development & Test
Trond Myklebust
<trond.myklebust@
fys.uio.no> To
Christopher T Vogan/San
01/12/2007 02:42 Jose/IBM@IBMUS
PM cc
[email protected]
Subject
Re: [NFS] FileID size with nfsv3
On Fri, 2007-01-12 at 11:31 -0600, Christopher T Vogan wrote:
>
> I had a question regarding NFSv3 Client and server but was not sure
> who to ask.
> The NFSv3 RFC states that NFSv3 should support 8 byte FILEID's. Does
> Linux
> support 8 byte FILEID's for NFSv3? It seems that most commands do
> support the use of large FileID's but gcc seems to have a problem.
>
> This is what I see in the RFC1813
> File attribute changes from NFSv2.
> The size and fileid fields have been widened to eight-byte unsigned
> integers from four-byte integers.
We don't currently export 64-bit inode numbers to userland on 32-bit
platforms because the code to allow getdents64() and stat64() to deal
with them was only recently merged into the kernel (as of 2.6.19).
I believe that David Howells does have patches that allows NFS to make
use of this new functionality, but he hasn't asked me to push them to
Linus yet. I'm not sure why.
Cheers,
Trond
On Fri, 2007-01-12 at 15:30 -0600, Christopher T Vogan wrote:
> Thanks Trond,
> So does this mean that Linux on a 64bit system supports 8 byte
> FileID's with NFSv3 now? Is there a time frame when these patches will
> be merged into the mainstream kernel? I am more interested in the
> client as it is connecting to ZFS file sytems on Sun. Snoop tracing
> showed the FileID was 8 bytes. but I got a message on the linux
> system "Value too large for defined data type". Now this message was
> produced by the running program but i expect that other user tools
> will have the same issue if they cannot handle stat64 calls.
> How can I get these patches from Dave?
That sounds like another issue. The fileid is currently converted into a
32-bit hashed value on pure 32-bit systems. That should, IOW, not be the
cause of your EOVERFLOW error.
Are you perhaps using an x86_64 system in 32-bit compatibility mode?
That would already be using 64-bit numbers internally, and would return
EOVERFLOW if you call the 32-bit stat(). David's patches won't help you
here. The only solution would be to ensure that your programs are
LFS-aware, and then to compile them using _FILE_OFFSET_BITS=64.
Cheers
Trond
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs