<div dir="ltr">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.<div><br></div><div><a href="http://apollo.backplane.com/DFlyMisc/nullfs01.patch">http://apollo.backplane.com/DFlyMisc/nullfs01.patch</a></div><div><br></div><div>Other questions I have are</div><div><br></div><div>(1) Jjust how many NULLFS filesystems</div><div>(2) Are you making multiple NFS mounts based on the same source path?  </div><div>(3) And finally, what is the underlying filesystem type that the nullfs is taking as its source?</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>-Matt</div></div>