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