Re: removing the statedump options file

Raghavendra Bhat <rabhat@xxxxxxxxxx> · Tue, 19 Feb 2013 12:57:39 +0530



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

    
      On Mon, Feb 18, 2013 at 11:03 PM,
        Raghavendra Bhat <rabhat@xxxxxxxxxx>
        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

          Gluster-devel@xxxxxxxxxx

          https://lists.nongnu.org/mailman/listinfo/gluster-devel