Nfs – ZFS over NFS v3 – “Invalid Argument” for empty files

nfszfs

I have OpenSolaris 2009.06 server providing ZFS over NFS v3 to a Linux 2.6.26 server. Does not happen when accessing the files via NFSv4.

Very happy. It catches silent data corruption in our LSI san. Great performance. Has snapshots. Has compression. Transaction log replay backups. Most importantly we no longer have FS caching issues and freezes that occurred on a Linux server.

There is one strange thing: Empty files are inaccessible from the Linux NFS client. When I try to ls, cat, or stat them I get:

stat: cannot stat `/srv/zpools/a/write.lock': Invalid argument

Rsync backups report:

rsync: readlink "/srv/zpools/a/write.lock" failed: Invalid argument (22)
rsync: readlink "/srv/zpools/userX/.netbeans/6.9/var/cache/mavenindex/netbeans/write.lock" failed: Invalid argument (22)
rsync: readlink "/srv/zpools/userX/.netbeans/6.9/var/cache/mavenindex/local/write.lock" failed: Invalid argument (22)
rsync: readlink "/srv/zpools/userX/javaPrograms/mavenProjects/thesis/libbn/target/test-classes/.netbeans_automatic_build" failed: Invalid argument (22)
rsync: readlink "/srv/zpools/userX/javaPrograms/mavenProjects/scalaCommon/target/test-classes/.netbeans_automatic_build" failed: Invalid argument (22)

I cannot reproduce it by creating new empty files only for some old files.

Can anyone tell what could the reason?

Edit: In the ZFS server, when stat'ing the strange files I found that the Modification time was in back 1927. 🙂 Touching the file on the server, fixed the problem on the NFS client.

Best Answer

The files were created in NFSv4 and received some unusual properties (e.g. the modification time is 40 years before the 1970 Unix epoch) and now they are invalid under NFSv3.