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
