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 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
