> I'm writing and testing a new piece of Ganesha code moving FSAL_PROXY > from NFSv4 to NFSv4.1. I'm facing regressions that we has introduced for few > months by lack of vigilance (basically : our FSAL_PROXY jenkins instance was > not active on the community ganesha gerrithub) (We plan as soon as possible > to plug again our FSAL_PROXY jenkins instance to community ganesha > gerrithub to avoid new regressions.) > > After fixing last week a first FSAL_PROXY regression about supported attrs, > I'm immediately facing the following new bug about a readdir regression by > running cthon basic readdir test : > > ./test6: readdir > ./test6: (/mnt/tmp/test3b.zBYU7Ly/cthon-b) didn't read expected > 'file.190' dir entry, pass 62 > ./test6: (/mnt/tmp/test3b.zBYU7Ly/cthon-b) didn't read expected > 'file.191' dir entry, pass 62 > ./test6: (/mnt/tmp/test3b.zBYU7Ly/cthon-b) didn't read expected > 'file.192' dir entry, pass 62 > ./test6: (/mnt/tmp/test3b.zBYU7Ly/cthon-b) didn't read expected > 'file.193' dir entry, pass 62 > ./test6: (/mnt/tmp/test3b.zBYU7Ly/cthon-b) didn't read expected > 'file.194' dir entry, pass 62 > ./test6: (/mnt/tmp/test3b.zBYU7Ly/cthon-b) didn't read expected > 'file.195' dir entry, pass 62 > ./test6: (/mnt/tmp/test3b.zBYU7Ly/cthon-b) didn't read expected > 'file.196' dir entry, pass 62 > ./test6: (/mnt/tmp/test3b.zBYU7Ly/cthon-b) didn't read expected > 'file.197' dir entry, pass 62 > ./test6: (/mnt/tmp/test3b.zBYU7Ly/cthon-b) didn't read expected > 'file.198' dir entry, pass 62 > ./test6: (/mnt/tmp/test3b.zBYU7Ly/cthon-b) didn't read expected > 'file.199' dir entry, pass 62 > ./test6: (/mnt/tmp/test3b.zBYU7Ly/cthon-b) Test failed with 10 errors > > This bug occurs on a basic FSAL_PROXY context with only one linux node > (NFSv4.1 client mounting on /mnt/tmp ; ganesha proxy ; local linux nfs server > exporting /tmp) . > > I know that a lot of work has been done during last month on "chunking for > readdir". Does anybody have a first idea or explanation about this > FSAL_PROXY "readdir" regression before I try to fix it ?
I might have messed up some things... The cookie the FSAL readdir is expected to return for an entry should be the cookie used to seek to the NEXT entry in the directory. With chunking, FSAL readdir may now be called with a non-NULL/non-zero starting cookie. The callback now returns a return code, not true/false, and unfortunately the meaning of "0" has flipped (it used to be stop, now it's continue...) Turn on cache inode and readdir debug and you may be able to see what's wrong if none of the above hints show up the issue. Frank --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
