[Gluster-users] [Gluster-devel] Re: [List-hacking] [bug #25207] an rm of a file should not cause that file to be replicated with afr self-heal.

[Keith Freedman]

ok, this does make sense.

I wont ask for details on implementation but it does seem to make 
sense to have it as a separate process.



At 09:27 PM 1/5/2009, Basavanagowda Kanur wrote:
>HEAL tool will monitor the glusterfs in the same way AFR currently 
>does. The only difference being HEAL is a seperate process.
>HEAL will contain all the functionalities of self-heal (inside AFR 
>as it exists today).
>
>On Mon, Jan 5, 2009 at 11:25 PM, Gordan Bobic 
><<mailto:gordan at bobich.net>gordan at bobich.net> wrote:
>Maybe I'm missing something here, but if you take self-healing out 
>of AFR, then surely that makes the system completely useless and no 
>better than running rsync every 5 minutes. Since that can't be 
>right, what am I missing?
>
>Gordan
>
>
>Anand Babu Periasamy wrote:
>Christopher, main issue with self-heal is its complexity. Handling 
>self-healing
>logic in a non-blocking asynchronous code path is difficult. 
>Replicating a missing
>sounds simple, but holding off a lookup call and initiating a new 
>series of calls
>to heal the file and then resuming back normal operation is tricky. 
>Much of the
>bugs we faced in 1.3 is related to self-heal. We have handled most 
>of these cases
>over a period of time. Self-healing is decent now, but not good 
>enough. We feel that
>it has only complicated the code base. It is hard to test and 
>maintain this part of
>the code base.
>
>Plan is to drop self-heal code all together once the active healing 
>tool gets ready.
>Unlike self-healing, this active healing can be run by the user on a 
>mounted file system
>(online) any time. By moving the code out of the file system, into a 
>tool (that is
>synchronous and linear), we can implement sophisticated healing techniques.
>
>Code is not in the repository yet. Hopefully in a month, it will be 
>ready for use.
>You can simply turn off self-heal and run this utility while the 
>file system is mounted.
>
>List-hacking is an internal list, mostly junk :). It is an internal 
>company list.
>We don't discuss technical / architectural stuff there. They are 
>mostly done over
>phone and in-person meetings. We do want to actively involve the 
>community right
>from the design phase. Mailing list is cumbersome and slow to interactively
>brainstorm design discussions. We can once in a while organize IRC sessions
>for this purpose.
>
>--
>Anand Babu
>
>Swank iest wrote:
>Well,
>
>I guess this is getting outside of the bug.  I suppose you are going 
>to mark it as not going to fix?
>
>I'm trying to put gluster into production right now, so may I ask:
>
>1) What are the current issues with self-heal that require a full 
>re-write?  Is there a place in the Wiki or elsewhere where it's 
>being documented?
>2) May I see the new code?  I must not be looking in the correct place in TLA?
>3) If it's not written yet, may I be included in the design 
>discussion?  (As I haven't put gluster into production yet, now 
>would be a good time to know if it's not going to work in the near future.)
>4) May I be placed on the 
><mailto:list-hacking at zresearch.com>list-hacking at zresearch.com 
>mailing list, please?
>
>  Christopher.
>
>  > Date: Mon, 5 Jan 2009 01:36:14 -0800
>  > From: <mailto:ab at zresearch.com>ab at zresearch.com
>  > To: <mailto:krishna at zresearch.com>krishna at zresearch.com
>  > CC: <mailto:swankier at msn.com>swankier at msn.com; 
> <mailto:list-hacking at zresearch.com>list-hacking at zresearch.com
>  > Subject: Re: [List-hacking] [bug #25207] an rm of a file should 
> not cause that file to be replicated with afr self-heal.
>  >
>  > Krishna, leave it as is. Once self-heal ensures that the volumes 
> are intact, rm will
>  > remove both the copies anyways. It is inefficient, but 
> optimizing it the current framework
>  > will be hacky.
>  >
>  > Swaniker, We are ditching the current self-healing framework 
> with an active healing tool.
>  > We can take care of it then.
>  >
>  >
>  > Krishna Srinivas wrote:
>  >> The current selfheal logic is built in lookup of a file, lookup is
>  >> issued just before any file operation on a file. So if the lookup call
>  >> does not know whether an open or rm is going to be done on the file.
>  >> Will get back to you if we can do anything about this, i.e to save the
>  >> redundant copy of the file when it is going to be rm'ed
>  >>
>  >> Krishna
>  >>
>  >> On Mon, Jan 5, 2009 at 12:19 PM, swankier 
> <<mailto:INVALID.NOREPLY at gnu.org>INVALID.NOREPLY at gnu.org> wrote:
>  >>> Follow-up Comment #2, bug #25207 (project gluster):
>  >>>
>  >>> I am:
>  >>>
>  >>> 1) delete file from posix system beneath afr on one side
>  >>> 2) run rm on gluster file system
>  >>>
>  >>> file is then replicated followed by deletion
>
>
>
>_______________________________________________
>Gluster-devel mailing list
><mailto:Gluster-devel at nongnu.org>Gluster-devel at nongnu.org
>http://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>
>
>
>--
>gowda
>_______________________________________________
>Gluster-users mailing list
>Gluster-users at gluster.org
>http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users