情况如下：
我们有一个文件服务器没有将时间戳保存到其文件的一小部分（数百万中的 77 个文件）。它改为写入 1969-12-31 19:00（Unix 纪元）的默认 mtime。
当这种情况发生时，它会不规则地发生，没有固定的模式（即这里的一个文件，那里的同一目录中的一组文件等）。以这种方式加盖时间戳的文件已通过 NFS 上传到服务器。
应该注意的是，我们只在此服务器上的 NFS 共享中看到这种情况，并且没有发生在任何服务器系统文件中，它似乎仅与 NFS 共享隔离。
一些附加信息：
- 服务器正在运行 Ubuntu Server 9.04
- NFSv4 用于文件服务。这是出口行：
/home/file_storage 10.0.0.1/24(rw,sync,no_root_squash,no_subtree_check) - 我们最近使用旧文件服务器中的 rsync 将文件迁移到此服务器
- 此服务器具有使用 3ware 9650SE 控制器的硬件 RAID 5 阵列。
- 文件系统是 ext3，在单个根分区上带有 LVM 和 LUKS/DMCRYPT
- 服务器定期与 ntpd 同步其时间。
更新
根据评论中的要求更新了上面的文件系统和分区信息。
RAID 控制器上的唯一挂载点是 /home/file_storage 吗？换句话说，该服务器上的其他文件系统是在同一个 RAID 控制器上还是在不同的控制器上？
如果 raid 控制器上唯一的东西是 nfs 共享，那么我担心会有 0 块被写入，并且您将它们视为日期归零。在不同的文件中运行一堆 md5sum 可能是值得的，然后在一周后运行它们并查看哪些已更改。
另一方面，如果您在同一个 raid 控制器上有很多文件系统，而唯一搞砸的是 nfs 共享一个，那么可能是网络数据包损坏了。我们在过去看到文件中有随机的 8k 0 块。即，每个人都认为nfs 块是写的，但实际上并非如此。这可能是网络问题，然后您应该会在界面上看到错误。
不过我会去第一个。
您是在本地还是仅在远程看到奇怪的时间？如果您担心文件系统集成，我会考虑从 CERN 运行文件系统检查器，当我可以找到它时，我会添加一个链接。（它会不断地将文件写入系统，然后等待并读取它）。
3ware卡一般都不错。
我对 NFS 上的文件时间的理解是它们通常由客户端设置，所以也许您有一台认为它始终为零时间的机器？