The two message were at the end of the Trash folder.
I used fuser to find the pids on the Trash and Trash.lock files. fuser
reported no pid for the Trash.lock file. The the ptruss was run on the
pid on the Trash file.
By synchronous writes I'm assuming on the nfs mount options? No, they
are async mounts.
Timo Sirainen wrote:
On Thu, 2009-07-30 at 10:07 -0600, CJ Keist wrote:
Okay,
I think I got a test that can recreate the .lock file staying around
so long. I have trash folder with about 3500 messages in it. I went in
and deleted two messages from the Trash folder.
How close to the end of the mailbox did you delete the messages from?
I then clicked back to
my inbox. There was a long pause where Thunderbird was saying " Closing
folder" Then another long pause as it said "Opening folder". After
about two minutes thunderbird looks to have stopped processing and
displayed my inbox. But the Trash.lock file stuck around for about
another 5 minutes.
Ran ptruss on the pid that still had the Trash folder open. There
was no pid for the Trash.lock file during this time.
What do you mean by this? Trash.lock didn't have a PID in it, but you
found the PID anyway somehow?
It looks to be
doing seeks, stats, reads and writes over and over again. Attached is a
partial listing of the ptruss command till the lock file went away.
It looks like you deleted some messages over 4 MB from the end of file,
and Dovecot just moves 4 MB data over the deleted one. It looks like
it's being done in pretty inefficient way though.. I guess I should some
day improve it, but that's probably going to be annoyingly difficult.
Anyway, if you look at where most of the time is spent, it's in the
pwrite64() calls. Many of them can take almost 0.1 seconds. Have you
enabled synchronous writes or something?
--
C. J. Keist Email: [email protected]
UNIX/Network Manager Phone: 970-491-0630
Engineering Network Services Fax: 970-491-5569
College of Engineering, CSU
Ft. Collins, CO 80523-1301
All I want is a chance to prove 'Money can't buy happiness'
