On Jun 17, 10:14am, Greg Hudson wrote:
} Subject: Re: SOFTDEPS safe for qmail?
} >>> If you add the second fsync to force the rename out to disk, you
} >>> should be all set..
} 
} >> Is that really guaranteed?
} 
} > It is guaranteed by softdep.  When you fsync() a file whose
} > directory entry has not been pushed to disk, the softdep code writes
} > the directory entry before fsync() returns.
} 
} Ah, someone who appears to know what they are talking about.  I have a
} few long-standing questions about FFS and softdep:

I helped Kirk McKusick debug some softdep panics caused by the softdep
kernel datastructures getting out of sync with the actual directory
contents.

} Suppose I open a new file, write to it, fsync it, and close it.  As
} you just said, with or without softdep, after the fsync() returns I
} can be sure that even if the machine reboots uncleanly RIGHT NOW the
} file exists on disk.

Yes, assuming your disk doesn't do write buffering.

In the classic UFS implementation, the file open would synchronously create
the inode and then the directory entry (always in that order to keep the
filesystem consistent), and the fsync() only has to push the data to disk.

With softdep, the inode and directory operations are deferred as is
actually writing the data.  Softdep is just careful to order the disk
writes so that the filesystem is always in a consistent state.  In order
to provide the same guarantees as classic UFS, fsync() in the softdep
implementation has to write the directory entry and inode to disk in
addition to the data.

} Now, suppose I rename() the file:
} 
} 	* Without softdep, after the rename() returns, can I assume
} 	  that if the machine reboots uncleanly RIGHT NOW, the file
} 	  will exist with the new name?

Yes.  Classic UFS has always done this synchronously so that it can
guarantee things are done in the right order to keep the filesystem in
a consistent state.

}         Does the answer change with
} 	  softdep?

Yes it does.

} 	* With softdep, if after the rename() I open the file,
} 	  fsync() it, and close() the file, can I be assured that the
} 	  rename has been committed?

I believe this is that case.  The fsync() should force out any pending
directory operations for the inode.  You can also skip the intermediate
close()/open() pair, assuming that you aren't using fclose() to flush
the stdio buffers (do fsync(), rename(), fsync(), close()).

} 	* With Linux ext2fs, I can open the directory, fsync() it, and
} 	  close the directory, and be certain that the rename is
} 	  committed.  (Although I'll trigger a bug in older versions
} 	  of the kernel and kill my performance, but let's ignore
} 	  that.)  Does that work in FFS, with or without softdeps?

I don't think you can open a directory for writing ...