DESC
Call fsync() on the journal directory because it's needed on some systems to
flush metadata.
EDESC

When we create a transaction file, we need to make sure not only the data hit
the disk, but the directory metadata too, so we can be absolutely sure we will
be able to access it.

Flushing directory metadata is quite messy because it's not clearly
standarized, so it depends a lot on the OS/Filesystem combination.

On some systems, fsync() over a file is guaranteed to flush also the metadata
needed to access the file (Linux/ext3, all BSDs), so nothing else is needed.

On other systems, fsync() on the directory holding the file is needed
(Linux/ext2). This is the proper Linux way to do things.

This gets even more weird, because it is also possible that neither works and
you need a sync() to do it, but the standard allows sync() to return before
the data has really hit the disk (although nobody sane do that these days,
some old systems work this way, eg. Linux < 1.3.20). Luckily, all current
systems seem to fall within the previous two categories.

God knows what happens over NFS on different client-server combinations. It
will probably work on most tho (at least from reading the source it seems like
Linux client and server do the right thing).

What this patch do is trying to cope with all those cases by always fsync()
the parent directory, and if that fails with EINVAL or EBADF, use sync(). It's
the best I can do.

Linux, FreeBSD, NetBSD, Solaris and MacOS X return OK when doing a directory
fsync(), so this should not cause unnecesary sync()s these days.

For reference, look at the huge number of posts of the subject on lkml, and
read fsync()'s SUSv3 reference.