Timo Sirainen wrote:

On Jun 24, 2008, at 7:31 PM, Amitai Schlair wrote:

...

Jun 24 12:22:13 chicken-ac dovecot: IMAP(schmonz): fdatasync_path(/home/schmonz/Maildir/.Trash/cur) failed: Bad file descriptor

What OS and filesystem do you use?

NetBSD 4.0, FFS with soft updates.

...

Jun 24 12:22:13 chicken-ac dovecot: Panic: IMAP(schmonz): file maildir-uidlist.c: line 1217 (maildir_uidlist_sync_update): assertion failed: (ctx->first_unwritten_pos != (unsigned int)-1)

Still shouldn't crash even if the fsync fails, I'll see about fixing that.

A workaround for now would be to se fsync_disable=yes

With the workaround, deleting works, and so copying sent messages to Sent will probably also work again (just about to find out :-).

Thanks for the quick response! If you need a fix tested, I can do that.

• Amitai

Same Problem here: both the failed fsync and the Panic.

What OS and filesystem do you use? NetBSD 4.0, Mails on NFS (server is a Debian box)

Still shouldn't crash even if the fsync fails, I'll see about
fixing that. Yes, please.

A workaround for now would be to se fsync_disable=yes Same workaround works for me.

No need to hurry, it's just a test server (production just moved from
1.0rc18 to 1.0.13).

On Jul 9, 2008, at 3:48 PM, Edgar Fuß wrote:

...

Apparently it doesn't like that I try to fsync() a read-only
directory file descriptor. I would argue that NetBSD is correct in this.

Posix says:

...

The fsync() function shall request that all data for the open file
descriptor named by fildes is to be transferred to the storage
device associated with the file described by fildes.

I read this a being about the file descriptor, not the file. Which
would imply that fsync()ing an O_RDONLY descriptor doesn't make sense.

However, the wording for fdatasync() is slightly different and not
as clear, whether intentional or not. But fdatasync() seems to be
conceptually about regular files anyway.

Dovecot isn't the only program trying to fsync directories. For
example sendmail does it too.

From an admittedly non-Linux perspective, I'm unsure why one would
need to perform a flush on a directory in the first place.

To make sure that if server crashes all the directory entries have
been written to disk by that time. So that:

1. fsync(tmp/newmail)
2. rename(tmp/newmail, new/newmail)
3. fsync(new/)
4. Reply OK to the sender

If there is no 3 and the server crashes just after 4, I don't think
the rename() was guaranteed to have reached the disk. The fsync(new/)
is supposed to guarantee this. If NetBSD doesn't support this, what
other way is there to do it? I'm guessing I could fsync(new/newmail)
again. But if I was creating a lot of mails, would I have to fsync()
all of the files?

(The reason why fsync(tmp/newmail) is done before rename is so that
half-written files won't show up in new/ directory in case of crashes,
so moving the fsync after rename doesn't solve the problem.)

I'll ask the question on tech-kern. It looks like there is no method of explicitly syncing a drectory; you'll have to sync the individual files instead.

The reason is probably that before the advent of soft updates, metadata write on FFS used to be syncronous anyway.

On Sat, 2008-07-19 at 22:57 +0200, Geert Hendrickx wrote:

On Tue, Jun 24, 2008 at 07:36:44PM +0300, Timo Sirainen wrote:

...

On Jun 24, 2008, at 7:31 PM, Amitai Schlair wrote:

...

Jun 24 12:22:13 chicken-ac dovecot: Panic: IMAP(schmonz): file
maildir-uidlist.c: line 1217 (maildir_uidlist_sync_update):
assertion failed: (ctx->first_unwritten_pos != (unsigned int)-1)

Still shouldn't crash even if the fsync fails, I'll see about fixing that.

Apart from the design issue of fsync'ing read-only directory file handles,

I guess this will do for now: http://hg.dovecot.org/dovecot-1.1/rev/a8331972aee5

have you been able to look into fixing the assert panic? :-)

http://hg.dovecot.org/dovecot-1.1/rev/1edff123dd8f probably fixes it?

...

A workaround for now would be to se fsync_disable=yes

Personally, I don't like this since (I assume) it disables fsync'ing of tmp/ files (mails uploaded via imap) as well?

Right.