Not saying I've got any solutions to the problem, just food for thought.
I was thinking that this would be better at the unify xlator, not the AFR.
AFR I would think just concentrates on duplicating the data, and the syncing
issue to be real time, wouldn't that naturally fall in the unify translator?
From: "Daniel van Ham Colchete" <daniel.colchete@xxxxxxxxx>
To: gluster-devel <gluster-devel@xxxxxxxxxx>
Subject: Re: Files erased while one brick was down in
AFRreturns from the afterlife
Date: Mon, 2 Jul 2007 17:44:15 -0300
Hi Krishna!
On 7/2/07, Krishna Srinivas <krishna@xxxxxxxxxxxxx> wrote:
Hi Daniel,
That case is not handled yet because of lack of time. Since its
not a risky thing to bring back a deleted file, it is in the TODO list
and yet to be fixed.
I know I'm not doing anything to solve the problem but this "not a risky"
unfortunately does not apply to me... One of the things I'll be doing with
GlusterFS is hosting e-mails. If I have to put one of the bricks in
maintenance (kernel/security update or something else) them every e-mail
downloaded or deleted by my users will reappear.
But if this will delay the release of version 1.3 them I also think it's in
the best interest of the project to delay this fix...
I'm a little bit worried because GlusterFS is, by far, the best option for
every storage application I need (email, a parallel database I'm planing,
web host, etc...), and soon (a few days) I'll be in production...
Versioning the directory is an option. Other things we can do -
journal the deletion or bring namespace awareness to AFR.
Thinking about my suggestion after sending the e-mail, I though that
versioning the directory might not be the best option. When I started
thinking about directory/subdirectories deletion/recreation things got too
ugly and the beautiful simplicity of GlusterFS was lost.
IMO namespace awareness to the AFR might bring a "chicken and the egg"
problem when planing to have no single point of failure in the project. Can
we use AFR to mirror the AFR's namespace? If yes, wouldn't it bring the
same
problem?
Journaling seems nice, but who reads the journal? And when? Where would it
be written? To every answer of those question I can think of performance
and
other problems the would arise...
This really requires a lot of thinking and also requires a lot more
understanding of everyone's storage needs than I have. I'm deeply sorry I
can't suggest a solution for you. May be I'm so tied to the problem that I
can't see the solution :).
Krishna
When you start working with this, please let-me know.
Best regards,
Daniel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxx
http://lists.nongnu.org/mailman/listinfo/gluster-devel
_________________________________________________________________
http://newlivehotmail.com
