Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
This error occurs when running the commands on the server hosting the ZFS filesystem? Or when running them on the Linux NFS client? –  larsks Dec 7 '10 at 21:01
    
It happens on the client side. –  Aleksandr Levchuk Dec 7 '10 at 21:09
    
What created the file? The NFSv3 client? –  Chris S Dec 7 '10 at 22:25
    
Chris, I think it might have been created by an NFSv4 client which we had earlier. NFSv4 had proven too fragile for an HPC cluster, so we switched everything to NFSv3. –  Aleksandr Levchuk Dec 7 '10 at 22:32
    
@Aleksandr : Does this problem happen for a new empty file (e.g. touch file). Also, does this happen if you use touch -m to change the modification time on a file to 1927? –  Stefan Lasiewski Dec 7 '10 at 22:38
show 1 more comment

1 Answer

up vote 1 down vote accepted

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.

share|improve this answer
    
+1, Thank you for posting what happened. Sounds like it might be the NFSv4 client has some bugs; or the NFSv3 client... –  Chris S Dec 9 '10 at 15:42
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.