I believe Inode_Size = 1114112; should be sufficient for pyNFS to pass. For iozone, I need Inode_Size = 33554432; But that's a *lot* of memory per inode. Daniel On 11/4/20 5:12 PM, Frank Filz wrote:
Good to know these failures are mostly already known.
On Fri, Oct 30, 2020 at 07:15:33AM -0700, Frank Filz wrote:
So the concerning failures for your test are WRT5a and SATT18.
SATT18 fails with this message in the log: Access check returned Forbidden action (new OWNER was not user)
That comes from fsal_helper.c. I put an extra log to confirm that attr->owner (what the request indicates the new owner should be) is 65534.
I guess it is expected that the tests are usually ran as sudo.
Ah, yes, that test won't do well if not root...
As for WRT5a, I set the inode size for the FSAL_MEM export to ~1MB (cargo- culted from a sample config file), and the file size for this FSAL appears to be capped at that. So any attempt to read bytes past the first inode worth of bytes returns 'a' bytes. See the line "isize += MEM.inode_size;" and the mem_read2 function in mem_handle.c.
Ok, that becomes an expected failure...
At the risk of overloading this thread, I noticed a more alarming bug. I added an assert in _mdcache_lru_unref to verify that the post-decremented refcount was non-negative. The assert failure can be triggered trivially (with FSAM_MEM, just mount the export and run "export foo > bar" in the root of the export). When the assert failed, the last two ref puts were at:
I'll defer to Daniel for looking at this one.
0 libganesha_nfsd.4.dylib 0x00000001069cd67b _mdcache_lru_unref + 443 1 libganesha_nfsd.4.dylib 0x00000001069bbbae mdcache_put_ref + 30 2 libganesha_nfsd.4.dylib 0x0000000106979867 compound_data_Free + 87 3 libganesha_nfsd.4.dylib 0x00000001069795bb nfs4_Compound + 1307 4 libganesha_nfsd.4.dylib 0x000000010690ff48 nfs_rpc_process_request + 4344 5 libganesha_nfsd.4.dylib 0x000000010690ed2c nfs_rpc_valid_NFS + 268 6 libntirpc.3.2.dylib 0x0000000106ae9b55 svc_vc_decode + 133 7 libntirpc.3.2.dylib 0x0000000106ae68e3 svc_request + 51 8 libntirpc.3.2.dylib 0x0000000106ae8d6f svc_vc_recv + 943 9 libntirpc.3.2.dylib 0x0000000106ae6805 svc_rqst_xprt_task_recv + 85 10 libntirpc.3.2.dylib 0x0000000106ae4ea1 svc_rqst_epoll_loop + 769 11 libntirpc.3.2.dylib 0x0000000106af0112 work_pool_thread + 402 12 libsystem_pthread.dylib 0x00007fff70cfc109 _pthread_start + 148 13 libsystem_pthread.dylib 0x00007fff70cf7b8b thread_start + 15
Which seems reasonable. The next one, which brought the refcount to -1, was:
0 libganesha_nfsd.4.dylib 0x00000001069cd67b _mdcache_lru_unref + 443 1 libganesha_nfsd.4.dylib 0x00000001069c3bba cih_remove_checked + 618 2 libganesha_nfsd.4.dylib 0x00000001069c37dd mdc_clean_entry + 1085 3 libganesha_nfsd.4.dylib 0x00000001069cfb67 mdcache_lru_clean + 919 4 libganesha_nfsd.4.dylib 0x00000001069cd8f9 _mdcache_lru_unref + 1081 5 libganesha_nfsd.4.dylib 0x00000001069bbbae mdcache_put_ref + 30 6 libganesha_nfsd.4.dylib 0x0000000106979867 compound_data_Free + 87 7 libganesha_nfsd.4.dylib 0x00000001069795bb nfs4_Compound + 1307 8 libganesha_nfsd.4.dylib 0x000000010690ff48 nfs_rpc_process_request + 4344 9 libganesha_nfsd.4.dylib 0x000000010690ed2c nfs_rpc_valid_NFS + 268 10 libntirpc.3.2.dylib 0x0000000106ae9b55 svc_vc_decode + 133 11 libntirpc.3.2.dylib 0x0000000106ae68e3 svc_request + 51 12 libntirpc.3.2.dylib 0x0000000106ae8d6f svc_vc_recv + 943 13 libntirpc.3.2.dylib 0x0000000106ae6805 svc_rqst_xprt_task_recv + 85 14 libntirpc.3.2.dylib 0x0000000106ae4ea1 svc_rqst_epoll_loop + 769 15 libntirpc.3.2.dylib 0x0000000106af0112 work_pool_thread + 402 16 libsystem_pthread.dylib 0x00007fff70cfc109 _pthread_start + 148 17 libsystem_pthread.dylib 0x00007fff70cf7b8b thread_start + 15
Of course, there is no guarantee that this is the "wrong" or extra ref put, but I can't see the ref get to correspond with this put. Any thoughts?
- Matt _______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org