On Thu, Nov 05, 2020 at 08:49:33AM -0500, Daniel Gryniewicz wrote:
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.
I don't think this is try for FSAL_MEM, which only allows one inode per file, and any attempt to read past the first inode results in 'a' bytes. See the results of `grep -rw datasize src/FSAL/FSAL_MEM`. I am only able to run FSAL_MEM (not even FSAL_VFS) in my hacked-together macOS setup. Note however that this issue isn't blocking me and not particularly troublesome (I will be writing my own FSAL in the coming weeks). Did you have a chance to look at the reference counting problem explained below?
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
Sorry, I meant to say `echo foo > bar` And by non-negative, I mean >= 0. Attached patch for clarity.
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