Messages in this thread | | | Date | Tue, 12 Mar 1996 19:17:21 -0500 | From | "Theodore Ts'o" <> | Subject | Re: 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
| |