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 address@hidden mailing list,
please?
Christopher.
> Date: Mon, 5 Jan 2009 01:36:14 -0800
> From: address@hidden
> To: address@hidden
> CC: address@hidden; address@hidden
> 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
<address@hidden> 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