[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.

[Gordan Bobic]

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