[lkml]   [1996]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: imapd and synchronous writes
fsync() isn't problem; it's doing what it's documented to do, which is
to flush the contents of file out to disk. This flushes out both the
data and the meta-data blocks. That isn't the problem, and this isn't a
bug. (fsync(), by the way, has been doing the right thing since 1.2.)

The problem which John is worried about is the data of the containing
directory, which fsync() does not concern itself with. And it can't,
really. When you call fsync(), you pass it a file descriptor; the
kernel has no way of knowing which one of potentially many containing
directories should also be flushed out to disk.

John's solution is to set the ext2 'S' attribute on the directory, and
this does work.

> crashes before that buffer gets flushed, the message gets lost. There
> is no way the application can commit the directory change short of
> calling sync().

Actually, there is, but it's not portable. If you open the directory
using open, and then call fsync on the resulting file descriptor, you
will forcibly commit the directory change. This is *not* guaranteed to
work on all POSIX systems, and indeed it may not work on many. But it
will work under Linux.

Still, it probably wouldn't be a bad idea for a paranoid application to
try opening the directory, and if the open succeeds, keep a handle on
that directory and call fsync() on that file descriptor after any
critical rename() calls. I suspect it shouldn't do any harm on most
Unix platforms.

- Ted

 \ /
  Last update: 2005-03-22 13:36    [W:0.051 / U:9.032 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site