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 renames the directory to ..DOVECOT-TRASH (or something like it) and only after that it starts unlinking the files. It wouldn't be too difficult to have this return success immediately and then keep deleting the files on the background. I'm not sure if this is worth the trouble though. It would also be possible to do this as a plugin. Something like that would be great. Would this actually then avoid the locking problem described below?
Incidently, the command that initially deleted those 35k messages to Trash took about 1 hour to complete on my server and effectively locked my account out for all that time. There were also an awlful lot of these output from my strace:
nanosleep({0, 131475000}, NULL) = 0 lstat("/home/virtual/xxx.com/home/admin/Maildir/.Folders.Porter/dovecot-uidlist.lock", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
You mean this was in the deleting process, or the other processes? The deleting process should have kept the maildir locked while it was deleting the files, so other processes were locked out. This is by design and can't be changed, at least until I some day add inotify support for maildir synchronization. You're probably right - another process is probably trying to access the folder that is currently being deleted and being prevented from doing so. There was an awlful lot of polling going on though - probably man tens per second. Not sure if this causes the system to thrash a bit and raise load unnecessarily.
If you renamed the folder to *.DOVECOT-DELETED or something you won't have another process trying to access the same folder and locking the account up.
IMHO this benefit is worth the effort. =)
Daniel