Hi,
on a clustered Dovecot server installation that was recently moved from a shared GPFS filesystem to GFS2, occasional corruptions in the users' INBOXes started appearing, where a new incoming message would be appended directly after a block of NUL bytes, and be scanned by dovecot as being glued to the preceding message.
I traced this to the file extension operation performed in mbox_sync_handle_eof_updates, where the 'file_set_size' call is used. If available, file_set_size will use the posix_fallocate call. In GFS2 posix_fallocate increases the file size in 4 kB chunks (there seems to be no guarantee anyway that posix_allocate will extend a file by the exact size requested).
After a successful posix_fallocate call, mbox_sync_handle_eof_updates currently proceeds in rewriting the mailbox starting from the originally intended 'file_size':
1306 if (file_set_size(sync_ctx->write_fd,
1307 file_size + -sync_ctx->space_diff) < 0) {
1308 mbox_set_syscall_error(sync_ctx->mbox,
1309 "file_set_size()");
1310 if (ftruncate(sync_ctx->write_fd, file_size) < 0) {
1311 mbox_set_syscall_error(sync_ctx->mbox,
1312 "ftruncate()");
1313 }
1314 return -1;
1315 }
1316 mbox_sync_file_updated(sync_ctx, FALSE);
1317
1318 if (mbox_sync_rewrite(sync_ctx, mail_ctx, file_size,
1319 -sync_ctx->space_diff, padding,
1320 sync_ctx->need_space_seq,
1321 sync_ctx->seq) < 0)
1322 return -1;When posix_fallocate extends the mailbox beyond the requested 'file_size', a variable size block of NUL bytes is left behind at the tail of the mailbox, with the side effects described above.
I successfully worked around this issue by undefining HAVE_POSIX_FALLOCATE, as the performance penalty with falling back to direct block appends seems small. At least a size check (and possible truncation) after the mbox_sync_file_updated call above should probably be added.
I thought that the issue would be anyway worth bringing to your attention.
Thanks. Francesco Prelz INFN - Sezione di Milano