0

I get error when I try to svn checkout on nfs mounted directory:

svn: E000079: Can't read directory /mnt/nfsdir: Value too large for defined data type.

  • Solaris 10
  • SVN 1.8.14
  • NFS server: QNAP TS 853 Pro
Ebru Yener
  • 121
  • 6

1 Answers1

1

NFS client is not supporting the NFS server version completely or NFS server has bug or subversion has bug.

I've encountered the problem on NFS 3. Solaris 10 NFS client had problem with linux NFS Server. (linux nfs bug )

First check the NFS version that your NFS server can provide.

$ rpcinfo -p qnapserver
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    ...
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    ...

Then use a different version for mounting:

mount -F nfs -o vers=2 19.19.19.19:sharethefact /mnt/thefact
Ebru Yener
  • 121
  • 6
  • Shouldn't that be `... -o vers=3 ...`? NFS version 2 doesn't support large files. And if you need to support large files, I'd opine that the server shouldn't even be configured to offer NFS version 2. – Andrew Henle Sep 08 '16 at 16:51
  • nope @Andrew. "Value too large for defined data type" is not about file size. my files are all source codes. something like uid/gid/timestamp or something exeeds the limits of nfs server filesystem. It is a bug or compatibility problem. – Ebru Yener Sep 08 '16 at 17:23
  • 1
    Do 64-bit processes have the same problem? If it's just 32-bit processes, the bug is likely with that program, as in this day and age it should be large-file aware and using 64-bit capable calls. From what you've posted, I'd bet `svn` is using `readdir()` instead of `readdir64()`. XFS/Irix-served NFS file systems would exhibit similar behavior since XFS uses inode values too large to fit in 32 bits. – Andrew Henle Sep 08 '16 at 17:59
  • SVN code may be the problem. We should check its source :) But at this time, I discovered a workaround to let business continue :) – Ebru Yener Sep 11 '16 at 13:04