https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292282
--- Comment #9 from Rick Macklem <[email protected]> --- (In reply to Martin Cracauer from comment #8) They can exist in the middle. The tradition (from UFS literally forever) is to expand the d_reclen field to assume free'd entries. However, this does not work for the first entry in a block. For the first entry in a block, mark it "invalid" by setting d_fileno (used to be called d_ino) to 0 (0 was never a valid inode#). NFS, the second type of file system for 4BSD, followed the same mechanism. As I mentioned, I did turn off expanding the last block to a full blocksize (8K at the moment) and committed the patch. bde@ noted that this broke directory block caching, with the cache miss rate increasing dramatically. I cannot remember why, but I reverted the patch that took it out. There is no reason why the Linux glue cannot take them out, since it appears to be broken now, anyhow. I can also tell you that the NFS readdir client code can easily be broken. (Disabling readahead exposes a race, to give you one example. Maintaining the correct directory offset cookies is not easy. As such, I have no urge to try and change it, to make it somehow "Linux compatible".) I also wonder what happens when Linux apps use the POSIX opendir(), readdir() function calls instead of the non-standard syscall. --> Someone could test this. Just write a little program on Linux that uses opendir(), readdir() and then try the binary on FreeBSD and see if it breaks? Note that I do not know if these entries with d_fileno == 0 are causing the breakage. It is just a hunch. I am not familiar with what the semantics of their getdents() syscall is, nor do I use the Linuxolator. -- You are receiving this mail because: You are the assignee for the bug.
