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

[Basavanagowda Kanur]

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 <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 list-hacking at zresearch.com mailing list,
>>> please?
>>>
>>>  Christopher.
>>>
>>>  > Date: Mon, 5 Jan 2009 01:36:14 -0800
>>>  > From: ab at zresearch.com
>>>  > To: krishna at zresearch.com
>>>  > CC: swankier at msn.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 <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
> Gluster-devel at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>



-- 
gowda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20090106/0910bfca/attachment-0003.html>