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