[Top] [All Lists]

Re: Question related to XFS sync , especially fsync

To: "Christoph Hellwig" <hch@xxxxxxxxxxxxx>
Subject: Re: Question related to XFS sync , especially fsync
From: "Gopala Krishna" <gopalakrishna.n.m@xxxxxxxxx>
Date: Wed, 16 Jan 2008 14:30:14 +0530
Cc: "Chris Wedgwood" <cw@xxxxxxxx>, nscott@xxxxxxxxxx, xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=q4/XuHgR6btpig686N/WD+ql5Hi/FGHyaR3hUUfmo/s=; b=TzWcBo58L8SmKA6hXi7wOaqALZ1uRr1/LhdsbLEFdmP3eIR9KcGqDXCUnIgE2K9JyQzv1uBhQE2BorzHy9RDq9tG7/KK/yqwFHUnmiovsD4YL44VBTMZECgAqY2HY6KAR1SgQ51leo8O3Jn8BJBfE8UnJNoOlOwX5VS9xOEDRAs=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=FNtH0qVGg/5WNncDqDyIXu+Sh8vRIGnc5iGTfNAKpcLM8dt9bhGLJjomls5FT+VlP6vKYgBd3gko/dBq5pEyBx4TcXbpVR2L7AILK8a/Fez3HZeo+3hdFsc+Ow3lM7SBm3xMvFM8odkly8gRZeYpjuGAae7MNDo1+BNcMc6T/8c=
In-reply-to: <20080116082502.GA24175@xxxxxxxxxxxxx>
References: <d711080c0801140414n48e47140y88f545eba605eff9@xxxxxxxxxxxxxx> <20080114224245.GT155259@xxxxxxx> <d711080c0801150544i53d7abb2hbea659116ce0006b@xxxxxxxxxxxxxx> <478CCEAC.9010008@xxxxxxxxxxx> <1200436012.9463.184.camel@xxxxxxxxxxxxxxxxx> <d711080c0801152243h7613bbean9daeab8658f75408@xxxxxxxxxxxxxx> <20080116064840.GA5725@xxxxxxxxxxxxxxxxxx> <d711080c0801152325g3d57965dm92e3687a5f98c5f6@xxxxxxxxxxxxxx> <20080116082502.GA24175@xxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
Thanks for the suggestions!.  I will relook at the my idea and
design....implemetation. As of now what we are doing is in experimental


On 1/16/08, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> 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.

[[HTML alternate version deleted]]

<Prev in Thread] Current Thread [Next in Thread>