Re: [PATCH] Btrfs: do not move em to modified list when unpinning

[Dave Chinner <david@fromorbit.com>]

On Fri, Nov 14, 2014 at 04:16:30PM -0500, Josef Bacik wrote:
> We use the modified list to keep track of which extents have been modified so we
> know which ones are candidates for logging at fsync() time.  Newly modified
> extents are added to the list at modification time, around the same time the
> ordered extent is created.  We do this so that we don't have to wait for ordered
> extents to complete before we know what we need to log.  The problem is when
> something like this happens
> 
> log extent 0-4k on inode 1
> copy csum for 0-4k from ordered extent into log
> sync log
> commit transaction
> log some other extent on inode 1
> ordered extent for 0-4k completes and adds itself onto modified list again
> log changed extents
> see ordered extent for 0-4k has already been logged
> 	at this point we assume the csum has been copied
> sync log
> crash
> 
> On replay we will see the extent 0-4k in the log, drop the original 0-4k extent
> which is the same one that we are replaying which also drops the csum, and then
> we won't find the csum in the log for that bytenr.  This of course causes us to
> have errors about not having csums for certain ranges of our inode.  So remove
> the modified list manipulation in unpin_extent_cache, any modified extents
> should have been added well before now, and we don't want them re-logged.  This
> fixes my test that I could reliably reproduce this problem with.  Thanks,

Is it possiible to turn this unspecified test in into another
generic fsync xfstest?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com