[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.018 / U:111.876 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site