[Dovecot] scalability and arhive ideas

[fernando at dfcom.com.br]

I´m not sure if i´m being quite clear about my solution (pardon my
english)...

I´m not thinking in any filesystem abstraction layer, I´m afraid of this
kind of solution. If some corruption happens we can loose data - and the
crash-recovery is not easy.

I´m suggesting the opposite, to not have an abstraction layer. The
abstraction layer would be the proxy - dovecot does the abstraction layer.
When I´m telling 'proxy' I meaning something like the proxy feature of the
dovecot.

And in my head the final solution is very 'simple' (despite of its hard
programming work). Dovecot just access 'in parallel' a set of servers,
requesting their informations (really, with imap connection) and caches
them - the results (maybe in some database, as you suggested). It would be
an extension of the proxy feature that already exists at dovecot.

Fernando


> On Tue, 2009-08-25 at 12:12 -0300, fernando at dfcom.com.br wrote:
>> Hi Timo,
>>
>> Yes it´s related, but I don´t understand '... You'll just need to
>> implement a filesystem that allows distributing a single user's mails to
>> multiple servers ...'.
>>
>> My idea is just in the direction that we don´t need to care about
>> filesystem, we don´t need any distribuited filesystem...let it be as
>> user
>> wants....at any some proxy level, the end storage can be ext3, reiser,
>> S.O
>> linux, freebsd, and so on.  I think that the more elements we insert,
>> the
>> more complex and hard to mount/debug the solution would be.
>
> I mean Dovecot accesses filesystem through a simple abstraction layer.
> You wouldn't have to implement a real OS level filesystem, but you'd
> implement a "proxying Dovecot-filesystem backend" that sits on top of
> real filesystems. It's probably not much of a difference to what you're
> thinking about, except in my mind it's entirely isolated from actual
> Dovecot code. There's just a simple API that the backend needs to
> implement and it'll work with Dovecot.
>
> BTW. Maybe http://www.xtreemfs.org/ or http://www.gluster.org/ already
> does what you're thinking about? I haven't looked at them closely
> enough..
>