Ok, you could try this kernel patch and see if it helps. If you know how to rebuild the system from sources. The client-side I/O errors would go hand-in-hand with the dotdot stuff, but only because this is a NFS mount. The server-side should not be having any I/O errors, and no filesystem data is in error or corrupted or anything like that.
http://apollo.backplane.com/DFlyMisc/nullfs01.patch Other questions I have are (1) Jjust how many NULLFS filesystems (2) Are you making multiple NFS mounts based on the same source path? (3) And finally, what is the underlying filesystem type that the nullfs is taking as its source? What I try to do in this patch is construct a FSID based on the nullfs's destination path instead of its source path, to try to reduce conflicts there. Another possible problem is that the nullfs's underlying filesystem has a variable fsid due to not being a storage-based filesystem. i.e. if the underlying filesystem is a NFS or TMPFS filesystem, for example. The only other thing that I can think of that could cause dotdot lookup failures is if you rename a directory on one client and try to access it from another, or rename a directory on the server and try to access it from a client that had already cached it. Directories are kinda finicky in NFS. -Matt
