7:17 p.m.
I am working on a VFS project, using Ganesha. We have our own FSAL module and export, and
we are using Ganesha's MDCACHE. In some scenarios a file is modified remotely, not via
the NFS front door. Our server already has support for noticing this. When something like
this happens we must invalidate cache entries. The plan to invalidate the kernel attr
cache is to do an open(2) syscall immediately followed by close(2) syscall in a background
thread. But that's not enough: before we do that we must invalidate Ganesha's
MDCACHE.
For invalidating the MDCACHE entry I think I need to use the invalidate "up
call" (https://github.com/phdeniel/nfs-ganesha/blob/master/src/include/fsal_up.h)
provided via the fsal_up_vector.
1) Am I going in the right direction? Any advice/gotchas to keep an eye on?
2) Maybe the update up call is better.
3) Maybe I should use up_async_invalidate (or up_async_update).
Thanks!
8:44 a.m.
New subject: Invalidating Ganesha MDCACHE attr entry from spawned off thread triggered by my FSAL
The invalidate UP calls are the correct calls to use. If you need your
thread back immediately, and don't care that the invalidate is done
inline, then you can use up_async_invalidate(), which will spawn a
thread and invalidate in the background. If it's okay to use your
thread, or you need to know that the invalidate is done before you
return out, then use the invalidate UP call directly.
Daniel
On 6/2/22 20:17, David Rieber via Devel wrote:
I am working on a VFS project, using Ganesha. We have our own FSAL
module and export, and we are using Ganesha's MDCACHE. In some scenarios a file is
modified remotely, not via the NFS front door. Our server already has support for noticing
this. When something like this happens we must invalidate cache entries. The plan to
invalidate the kernel attr cache is to do an open(2) syscall immediately followed by
close(2) syscall in a background thread. But that's not enough: before we do that we
must invalidate Ganesha's MDCACHE.
For invalidating the MDCACHE entry I think I need to use the invalidate "up
call" (https://github.com/phdeniel/nfs-ganesha/blob/master/src/include/fsal_up.h)
provided via the fsal_up_vector.
1) Am I going in the right direction? Any advice/gotchas to keep an eye on?
2) Maybe the update up call is better.
3) Maybe I should use up_async_invalidate (or up_async_update).
Thanks!
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
4:15 p.m.
New subject: 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?
5:35 p.m.
New subject: Invalidating Ganesha MDCACHE attr entry from spawned off thread triggered by my FSAL
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
695
days inactive
695
days old
3 comments
3 participants
participants (3)
-
Daniel Gryniewicz -
David Rieber -
Frank Filz