On Thu, 2008-01-31 at 10:01 +, Daniel Watts wrote:
> Hi Timo,
> > On Jan 29, 2008, at 6:03 PM, Daniel Watts wrote:
> >
> >> Is there not a more efficient way to do this? If Dovecot knows the
> >> whole folder is being deleted (ie a Trash purge), could it do
> >> something clever with the file
Hi Timo,
On Jan 29, 2008, at 6:03 PM, Daniel Watts wrote:
Is there not a more efficient way to do this? If Dovecot knows the
whole folder is being deleted (ie a Trash purge), could it do
something clever with the filesystem to just remove the whole folder?
If you use IMAP DELETE command, it
On Wed, 30 Jan 2008, Benjamin R. Haskell wrote:
On Wed, 30 Jan 2008, Gabriel Millerd wrote:
Making a perl script to insert 35k emails using dovecot deliver
doesn't impact my under resourced machines and I work with
spam/(false|ham|queue) system with mail::imapclient automation and the
script f
On Wed, 30 Jan 2008, Gabriel Millerd wrote:
On 1/30/08, Ed W <[EMAIL PROTECTED]> wrote:
Just get a small shell script to run `touch ${rand_file}` 35,000 times
and time it. Then drop into your shell and do rm -rf on the folder
(for bonus marks you could purge the disk cache before doing this
On Jan 29, 2008, at 6:03 PM, Daniel Watts wrote:
Is there not a more efficient way to do this? If Dovecot knows the
whole folder is being deleted (ie a Trash purge), could it do
something clever with the filesystem to just remove the whole folder?
If you use IMAP DELETE command, it renames
On 1/30/08, Ed W <[EMAIL PROTECTED]> wrote:
>
>
> Just get a small shell script to run `touch ${rand_file}` 35,000 times
> and time it. Then drop into your shell and do rm -rf on the folder
> (for bonus marks you could purge the disk cache before doing this).
> This gives you a benchmark on your
On Wed, 30 Jan 2008, Ed W wrote:
I misunderstood the cause of the slowness then, if it is really true that
updating the index is not an important factor. I don't remember seeing
profiling, but since I don't have any myself I'll take your word for it.
It always frustrates me to see peop
I misunderstood the cause of the slowness then, if it is really true
that updating the index is not an important factor. I don't remember
seeing profiling, but since I don't have any myself I'll take your
word for it.
It always frustrates me to see people speculate on stuff instead of
On Tue, 29 Jan 2008, Bill Cole wrote:
At 6:32 PM -0800 1/29/08, Asheesh Laroia imposed structure on a stream
of electrons, yielding:
On Tue, 29 Jan 2008, Bill Cole wrote:
For Dovecot, the mailbox index also has to be updated for each
deletion, and while that in itself is not terribly expensiv
At 6:32 PM -0800 1/29/08, Asheesh Laroia imposed structure on a
stream of electrons, yielding:
On Tue, 29 Jan 2008, Bill Cole wrote:
For Dovecot, the mailbox index also has to be updated for each
deletion, and while that in itself is not terribly expensive per
message, it has to be done one m
On Tue, 29 Jan 2008, Bill Cole wrote:
For Dovecot, the mailbox index also has to be updated for each deletion,
and while that in itself is not terribly expensive per message, it has
to be done one message at a time to maintain consistency between the
index and the real mail.
In general, this
At 4:03 PM + 1/29/08, Daniel Watts wrote:
Hi,
I've straced a few dovecot processes after hitting purge on a large
Trash folder (35,000 messages). It looks like it is going through
each message, one by one, and removing (unlinking) each one.
Is there not a more efficient way to do this? I
Hi,
I've straced a few dovecot processes after hitting purge on a large
Trash folder (35,000 messages). It looks like it is going through each
message, one by one, and removing (unlinking) each one.
Is there not a more efficient way to do this? If Dovecot knows the whole
folder is being dele
13 matches
Mail list logo
