[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gluster-devel] Re: [List-hacking] [bug #25207] an rm of a file should n
Anand Babu Periasamy
[Gluster-devel] Re: [List-hacking] [bug #25207] an rm of a file should not cause that file to be replicated with afr self-heal.
Mon, 05 Jan 2009 02:30:29 -0800
Mozilla-Thunderbird 184.108.40.206 (X11/20081018)
Christopher, main issue with self-heal is its complexity. Handling self-healing
logic in a non-blocking asynchronous code path is difficult. Replicating a
sounds simple, but holding off a lookup call and initiating a new series of
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
over a period of time. Self-healing is decent now, but not good enough. We feel
it has only complicated the code base. It is hard to test and maintain this
the code base.
Plan is to drop self-heal code all together once the active healing tool gets
Unlike self-healing, this active healing can be run by the user on a mounted
(online) any time. By moving the code out of the file system, into a tool (that
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
You can simply turn off self-heal and run this utility while the file system is
List-hacking is an internal list, mostly junk :). It is an internal company
We don't discuss technical / architectural stuff there. They are mostly done
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.
Swank iest wrote:
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
2) May I see the new code? I must not be looking in the correct place
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?
> 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
>> On Mon, Jan 5, 2009 at 12:19 PM, swankier <address@hidden>
>>> 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
>>> Reply to this item at:
> Anand Babu Periasamy
> GPG Key ID: 0x62E15A31
> Blog [http://ab.freeshell.org]
> GlusterFS [http://www.gluster.org]
> The GNU Operating System [http://www.gnu.org]
Visit messengerbuddies.ca to find out how you could win. Enter today.
Anand Babu Periasamy
GPG Key ID: 0x62E15A31
The GNU Operating System [http://www.gnu.org]
- [Gluster-devel] Re: [List-hacking] [bug #25207] an rm of a file should not cause that file to be replicated with afr self-heal.,
Anand Babu Periasamy <=