On 05/31/17 18:20, Frank Filz wrote:
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
Hi Frank,
Many thanks for your answer. I found and fixed the bug. The regression
was due to the fact that the readdir callback status was taken into
account only into pxy_do_readdir but not in the upper wrapper pxy_readdir.
The fixing patch is submitted to gerrithub :
https://review.gerrithub.io/#/c/363408/ .
Thanks,
--
Patrice LUCAS
Ingenieur-Chercheur, CEA-DAM/DSSI/SISR/LA2S
tel : +33 (0)1 69 26 47 86
e-mail : patrice.lu...@cea.fr
------------------------------------------------------------------------------
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
