4:10 p.m.
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(a)lists.nfs-ganesha.org To unsubscribe send an email
to
> > devel-leave(a)lists.nfs-ganesha.org
>