<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 02/19/2013 12:47 PM, Anand Avati
wrote:<br>
</div>
<blockquote
cite="mid:CAFboF2xYXVavuOJNDpCgHi7YYF2DzyWUy5Vg_UnyyEkKFBoAQQ@mail.gmail.com"
type="cite"><br>
<br>
<div class="gmail_quote">On Mon, Feb 18, 2013 at 11:03 PM,
Raghavendra Bhat <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:rabhat@redhat.com" target="_blank">rabhat@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> <br>
Hi,<br>
<br>
As of now when statedump command is issued via cli (gluster
volume statedump <volname> [options]) depending upon
what options is given via cli a temporary file
(glusterdump.<pid>.options) file is created by
glusterd and glusterfsd process read that file to decide
what information should be dumped. But the problem is
glusterd after issuing the SIGUSR1 signal to the glusterfsd
processes, sleeps for 1 second and then unlinks the options
file. To fix that a patch was sent ( <a
moz-do-not-send="true"
href="http://review.gluster.org/#change,2585"
target="_blank">http://review.gluster.org/#change,2585</a>),
where<br>
<br>
* the glusterfsd process after dumping the information to
the statedump file, unlinked the options by (instead of
glusterd doing it)<br>
<br>
Another approach suggested to me was this:<br>
<br>
* Have a separate thread in glusterd which keeps on polling
for the file glusterdump.<pid>.options.over (i.e some
renamed file). glusterfsd after dumping the information,
renames the options file and thats when glusterd realizes
the statedump is taken and unlinks the file. (The new thread
is spawned whenever statedump is issued and is finished
after unlinking the renamed options file).<br>
<br>
</div>
</blockquote>
<div><br>
</div>
<div>If the purpose of the other thread is to just keep polling
for rename() to complete and eventually delete, why not just
let the file be deleted by glusterfsd? If glusterd needs to
know when glusterfsd "finished its work", then instead of
polling for rename, it could just poll for unlink() of the
options file, no?</div>
<div><br>
</div>
<div>Avati</div>
</div>
</blockquote>
I think the 1st method where glusterfsd unlinks the file is ok.
Because glusterd says statedump is successful or unsuccessful right
after issuing the SIGUSR1 signal to the brick processes. Here the
whole purpose of the new thread would be just to unlink the file. It
just exits after unlinking the file. If glusterfsd itself unlinks
the file, then there is no need for the new thread at all, as all
it would be doing is get spawned, wait till the file gets unlinked
by glusterfsd and then exit (without doing anything as informing the
user about success/failure of statedump would have been done right
after issuing SIGUSR1 signal to the brick process itself).<br>
<br>
Regards,<br>
Raghavendra Bhat<br>
<blockquote
cite="mid:CAFboF2xYXVavuOJNDpCgHi7YYF2DzyWUy5Vg_UnyyEkKFBoAQQ@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> Please let me know the
inputs.<br>
<br>
<br>
Regards,<br>
Raghavendra Bhat<br>
</div>
<br>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:Gluster-devel@nongnu.org">Gluster-devel@nongnu.org</a><br>
<a moz-do-not-send="true"
href="https://lists.nongnu.org/mailman/listinfo/gluster-devel"
target="_blank">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br>
<br>
</blockquote>
</div>
<br>
</blockquote>
<br>
<br>
</body>
</html>