[Gluster-devel] Update md-cache after triggering FOP via syncop framework?

[Niels de Vos]

On Tue, Jun 05, 2018 at 11:04:00AM +0200, David Spisla wrote:
> Hello Niels,
> 
> thank you. Now I understand this better.
> I am triggering the FOPs via syncop directly from the WORM Xlator which is
> unfortunately below the upcall xlator.
> I don't have a separate xlator, so I am searching for a solution which is
> working inside of the WORM Xlator.
> E.g. the autocommit function of the WORM Xlator is using the syncop
> framework to change the atime
> of a file. I don't know if there is a difference between FOPs triggered by
> syncop or by clients from outside.
> My guess is that there is no difference, but I am not sure.

You can experiment with moving the WORM xlator in the .vol files of the
bricks before upcall, just restart the brick processes after editing the
config files.

I can not immediately think of a reason why this would cause problems.
You could send a patch that explains your need and changes the location
of WORM (or upcall?) in the graph (see server_graph_table in
xlators/mgmt/glusterd/src/glusterd-volgen.c).

Niels


> 
> Regards
> David
> 
> 2018-06-05 9:51 GMT+02:00 Niels de Vos <ndevos at redhat.com>:
> 
> > On Mon, Jun 04, 2018 at 03:23:05PM +0200, David Spisla wrote:
> > > Dear Gluster-Devels,
> > >
> > > I'm currently using the syncop framework to trigger certain file
> > operations
> > > within the Server Translators stack. At the same time, file attributes
> > such
> > > as file rights and timestamps are changed (atime, mtime). I noticed that
> > > the md-cache does not get the changed attributes or only when the upcall
> > > xlator is activated eg by a READDIR (executing " $ stat * ").
> > > However, I would find it cleaner if right after triggering a file
> > operation
> > > by the syncop framework that would update md-cache. Is there a way to
> > > programmatically do this within the Server Translators stack?
> >
> > Hi David,
> >
> > If you place your xlator above upcall, upcall should inform the clients
> > about the changed attributes. In case it is below upcall, the internal
> > FOPs can not be tracked by upcall.
> >
> > Upcall tracks all clients that have shown interest in a particular
> > inode. If that inode is modified, the callback on the brick stack will
> > trigger a cache-invalidation on the client. I do not think there should
> > be a difference between FOPs from other clients, or locally created ones
> > through the syncop framework.
> >
> > In case this does not help or work, provide a little more details (.vol
> > file?).
> >
> > HTH,
> > Niels
> >