5:35 p.m.
You may want to be careful about making Ganesha calls on a non-Ganesha thread. One option
is to have a worker thread you can dispatch to. If you must make Ganesha calls on a
non-Ganesha thread, you should definitely set up an op_context and fill in all the bits
you need from it and then access that from the non-Ganesha thread. You will want to
consider refcounting and properly managing if your export in removed by unexport. Note
that in calling up to mdcache, you need to make a super-call to swizzle things properly so
mdcache will have the correct context.
Frank
-----Original Message-----
From: David Rieber via Devel [mailto:devel@lists.nfs-ganesha.org]
Sent: Friday, June 3, 2022 2:15 PM
To: devel(a)lists.nfs-ganesha.org
Subject: [NFS-Ganesha-Devel] Re: Invalidating Ganesha MDCACHE attr entry
from spawned off thread triggered by my FSAL
Thank you for the quick response Daniel. A follow up question: I need the
fsal_up_vector to make the invalidate UP call. My server receives the occasional
"remote" change to some path (by remote I mean not coming through
Ganesha's "front door"). Therefore, when I want to call
fsal_up_vector.invalidate (or its async variant) I am not in a ganesha thread, and
therefore I think I will not have a req_op_context pointer.
I plan to workaround this by capturing the "const fsal_up_vector*" inside the
create_export call and saving the pointer in my own data structure for later use.
Is this a reasonable plan? Any gotchas?
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org To unsubscribe send an email to
devel-leave(a)lists.nfs-ganesha.org