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
