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.