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: cj.keist@colostate.edu 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'