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
