Re: Question related to XFS sync , especially fsync

[Christoph Hellwig <hch@infradead.org>]

On Wed, Jan 16, 2008 at 12:55:17PM +0530, Gopala Krishna wrote:
> While  replying  to Eric, I mentioned why we are doing that. We are
> basically providing interfaces to back up applications in a pure storage
> environment that deals with the  back up at block level (sector level) and
> hence depending upon different file system, we need to get information about
> file like it's extent information and associated block numbers etc.

This basically can't work.  If you do a plain block based backup you
need to freeze the filesystem first and then either backup through a
newly created snapshot or the raw device.  Alternatively you can do
file-based backups assisted by the bulkstat interface as done by
xfsdump.  If you try to mix the two layers you get into deep trouble
due to various issues:

 - knowledge of the disk format.  The ondisk format can change anytime
   and will break your application.  And yes, additions to the ondisk
   format do happen quite frequently.
 - no coherency between the filesystem and the block device node.  This
   is especially true for backup applications which use the buffered
   block device nodes because there is a real-life chance that stale
   cache is around
 - no guarantee that the ondisk image is actually update.  XFS like
   most other current filesystems uses an intent log to provide
   reliabily and sync is only guaranteed to push updates into the log
   but not actually write it back to it's "normal" location on disk.

In short what you're trying to do is a road to disaster, so don't do it!

Note that the problems apply to any filesystem in one way or another,
not just XFS.