2:52 p.m.
Lookup in a directory should use a read lock, however, if the entry isn’t in cache, it
switches to a write lock so it can add the entry to cache.
Hmm, if serializing lookups is a problem, we could maybe do a trylock, and if it fails, do
the lookup uncached. I don’t know if that would help things or hurt, might be an
interesting avenue to explore.
Frank
From: Alok Sinha [mailto:alok@spillbox.io]
Sent: Wednesday, August 28, 2019 9:44 AM
To: Matt Benjamin <mbenjami(a)redhat.com>
Cc: Ganesha-devel <devel(a)lists.nfs-ganesha.org>
Subject: [NFS-Ganesha-Devel] Re: request from clients
Hi Matt,
This is resolved. Lookup locks directory, not open. I have my own FSAL and moved some
operation
from open to lookup and found different behavior.
So lookup in a directory is sequential while open is parallel. I am OK with this.
Thanks.
-alok
On Wed, Aug 28, 2019 at 9:30 AM Matt Benjamin <mbenjami(a)redhat.com
<mailto:mbenjami@redhat.com> > wrote:
Hi Alok,
What does tcpdump see?
Matt
On Wed, Aug 28, 2019 at 12:11 PM Alok Sinha <alok(a)spillbox.io
<mailto:alok@spillbox.io> > wrote:
I am new to Ganesha and file system.
I seeing a problem and need advice.
On a client machine , I fork multiple processes
each reading a different file in a same directory.
I expect that Ganesha will see requests for files
coming in parallel. In real world, I see that fsal_lookup
sees one file at a time. Is this expected? For Ganesha,
i see that requests are serial while I expect or rather want to
force parallel.
-alok
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
<mailto:devel@lists.nfs-ganesha.org>
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
<mailto:devel-leave@lists.nfs-ganesha.org>
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103
http://www.redhat.com/en/technologies/storage
tel. 734-821-5101
fax. 734-769-8938
cel. 734-216-5309