Os arquivos foram criados no NFSv4 e receberam algumas propriedades incomuns (por exemplo, o tempo de modificação é de 40 anos antes da época do Unix de 1970) e agora eles são inválidos sob o NFSv3.
Eu tenho o servidor OpenSolaris 2009.06 fornecendo o ZFS sobre o NFS v3 para um servidor Linux 2.6.26. Não acontece ao acessar os arquivos via NFSv4.
Muito feliz. Ele pega a corrupção silenciosa de dados em nosso LSI san. Grande performance. Tem instantâneos. Tem compressão. Backups de repetição do log de transações. Mais importante ainda, não temos mais problemas de cache e congelamento do FS que ocorreram em um servidor Linux.
Há uma coisa estranha: arquivos vazios são inacessíveis do cliente Linux NFS. Quando eu tento ls, cat, ou stat eles eu recebo:
stat: cannot stat '/srv/zpools/a/write.lock': Invalid argument
Relatório de backups do Rsync:
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)
Não consigo reproduzi-lo criando novos arquivos vazios apenas para alguns arquivos antigos.
Alguém pode dizer o que poderia o motivo?
Editar: No servidor ZFS, ao declarar os arquivos estranhos, descobri que o tempo de modificação estava em 1927. :) Tocando o arquivo no servidor, corrigiu o problema no NFS cliente.