xfs
[Top] [All Lists]

Re: SEEK_DATA/SEEK_HOLE support

To: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Subject: Re: SEEK_DATA/SEEK_HOLE support
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 6 Oct 2011 11:32:34 +1100
Cc: xfs@xxxxxxxxxxx, Christoph Hellwig <hch@xxxxxxxxxxxxx>, Jeff Liu <jeff.liu@xxxxxxxxxx>
In-reply-to: <201110052022.19953@xxxxxx>
References: <4E887D7F.2010306@xxxxxxxxxx> <201110050934.28021@xxxxxx> <20111005093615.GQ3159@dastard> <201110052022.19953@xxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Wed, Oct 05, 2011 at 08:22:18PM +0200, Michael Monnerie wrote:
> On Mittwoch, 5. Oktober 2011 Dave Chinner wrote:
> > It's a data corruption problem, pure and simple....
> 
> Thanks for the thorough explanation. So it's a problem when a file has 
> recently been modified and not yet been written back to disk. Would it 
> be worth to force a flush to disk before SEEK_* operations can start? I 
> don't know if it's easier to do all the lookups you suggested, or do an 
> fsync. That could have it's own impacts, though.

The problem is that application does not know whether fsync is
needed or not, so it would have to do that unconditionally for every
file it was copying. That has potential for quite severe, unexpected
performance regressions, so it's something we want to avoid.

There isn't really any additional complexity on the side of the
XFS SEEK_XXX code to handle this properly - my comments were
aimed at making sure that everyone understood the constraints of
taking parts of the XFS code and making it a generic helper because
other filesystems do not have the same locking heirachyi or
unwritten extent implementation as XFS does....

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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