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