Again, we write a couple of files to UFS, doing an fsync for each.
When we simulate a crash by drawing the plug, we find that
after reboot all newer files, say the last 30 or so, have
been moved to lost+found, admittedly with
correct content. This is however of no real use for us,
because we cannot tell, which file in
lost+found is which. This behaviour is specific to 2.6 only.
In 2.5 it worked okay, in 2.7 it works if we mount with
mount option "logging". On AIX and HP-UX it also
works fine, in all OS releases of the last years.
On NT we use _commit() instead of fsync(), and it works fine.
By doing an fsync, we expect the file to be on
disk, complete with data blocks, inode AND
directory entry. True, the man page on fsync does
not explicitly mention the directory entry, but no
man page of any Unix (as far as I know) does, and
still it works as expected on most of them.
What good is it to have the data on disk
somewhere, but the filename has gone?
At first we supposed we were just overlooking
something trivial like a configuration option, or like the
"logging" option on 2.7. But now apparently this
behaviour can not be changed, and only we consider
it a bug? No one else has the need to be
absolutely sure at some point in time that a new file
is truly written to disk AND accessible?
M.Uhlenberg, iXOS AG