gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] removing the statedump options file


From: Raghavendra Bhat
Subject: Re: [Gluster-devel] removing the statedump options file
Date: Tue, 19 Feb 2013 12:57:39 +0530
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

On 02/19/2013 12:47 PM, Anand Avati wrote:


On Mon, Feb 18, 2013 at 11:03 PM, Raghavendra Bhat <address@hidden> wrote:

Hi,

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 ( http://review.gluster.org/#change,2585), where

* the glusterfsd process after dumping the information to the statedump file, unlinked the options by (instead of glusterd doing it)

Another approach suggested to me was this:

* 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).


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?

Avati
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).

Regards,
Raghavendra Bhat
 
Please let me know the inputs.


Regards,
Raghavendra Bhat

_______________________________________________
Gluster-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/gluster-devel





reply via email to

[Prev in Thread] Current Thread [Next in Thread]