Re: [Gluster-devel] Update md-cache after triggering FOP via syncop framework?
Hello Niels, yes, this seems to be a good idea. In a few hours I have to travel to an IT conference. So I will start to try your suggestion next week. Regards David 2018-06-05 11:44 GMT+02:00 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 : > > > > > 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 > > > > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Update md-cache after triggering FOP via syncop framework?
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 : > > > 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 > > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Update md-cache after triggering FOP via syncop framework?
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. Regards David 2018-06-05 9:51 GMT+02:00 Niels de Vos : > 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 > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Update md-cache after triggering FOP via syncop framework?
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 signature.asc Description: PGP signature ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
