directory fsyncs

pacman (pacman-kernel@cqc.com)
Tue, 22 Sep 1998 23:50:18 -0500 (EST)


A while ago there was a major flamewar on filesystem reliability, which ended
in the conclusion that if you want certain operations to be guaranteed to be
committed to disk in the order you requested them, you need to fsync the
directory in which they were performed.

Has anyone documented the exact semantics of directory fsync'ing? Where is
the list of operations that need to be directory-fsync()d? Off the top of my
head, I would guess creat(), link(), unlink(), rename() (for rename, you
would have to fsync both source and destination directories, right?),
mkdir(), and rmdir() Are there any others? What is the recommended calling
sequence for the fsync'ing of directories? I feel nervous about using open
and close instead of opendir and closedir, but we are in Linux-specific
territory here, so maybe I shouldn't. Any chance of getting this stuff added
to our fsync.2 man page? I'll volunteer to write it up once I've gathered all
the answers to my questions.

While we're on the subject, I've realized I'm uncertain about the scope of
fsync in general. What is the true meaning of fsync(fd)?

A. commit to disk all write()s that occurred on that descriptor
B. commit to disk all write()s that occurred to that file in this process
C. commit to disk all write()s that occurred to that file in _any_ process
D. something else

(For this question I'd appreciate both the Linux answer and the minimal POSIX
guarantee, if they are different.)

I originally thought A was the case, but now that I think about it, if that
were true, it wouldn't make any sense at all to open a directory and fsync it
after a creat(), since the fd in question isn't related to the creat.

-- 
Alan Curry

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/