Re: Files erased while one brick was down in AFR returns from the afterlife

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Daniel,
 Nice suggestion! versioning directories makes sense. Each subdirectory can
be treated a seperate 'problem' and be solved nicely. a given directory's
version will only imply existance or non-existance of its subdirectory, and
not the contents of the subdirectory. I dont see why it can get messy? This
will (if at all) get into the first release post 1.3-STABLE.

thanks,
avati

2007/7/3, Daniel van Ham Colchete <daniel.colchete@xxxxxxxxx>:

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




--
Anand V. Avati


[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux