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@redhat.com>
Cc: Ganesha-devel <devel@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@redhat.com> wrote:

Hi Alok,

What does tcpdump see?

Matt

On Wed, Aug 28, 2019 at 12:11 PM Alok Sinha <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@lists.nfs-ganesha.org
> To unsubscribe send an email to 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