Btrfs: don't clear uptodate if the eb is under IO
authorJosef Bacik <jbacik@fb.com>
Fri, 28 Mar 2014 21:07:27 +0000 (17:07 -0400)
committerChris Mason <clm@fb.com>
Mon, 7 Apr 2014 00:34:37 +0000 (17:34 -0700)
commita26e8c9f75b0bfd8cccc9e8f110737b136eb5994
tree678d0c7e3611739b89ca851c868ab8892a70effa
parent573a075567f0174551e2fad2a3164afd2af788f2
Btrfs: don't clear uptodate if the eb is under IO

So I have an awful exercise script that will run snapshot, balance and
send/receive in parallel.  This sometimes would crash spectacularly and when it
came back up the fs would be completely hosed.  Turns out this is because of a
bad interaction of balance and send/receive.  Send will hold onto its entire
path for the whole send, but its blocks could get relocated out from underneath
it, and because it doesn't old tree locks theres nothing to keep this from
happening.  So it will go to read in a slot with an old transid, and we could
have re-allocated this block for something else and it could have a completely
different transid.  But because we think it is invalid we clear uptodate and
re-read in the block.  If we do this before we actually write out the new block
we could write back stale data to the fs, and boom we're screwed.

Now we definitely need to fix this disconnect between send and balance, but we
really really need to not allow ourselves to accidently read in stale data over
new data.  So make sure we check if the extent buffer is not under io before
clearing uptodate, this will kick back EIO to the caller instead of reading in
stale data and keep us from corrupting the fs.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
fs/btrfs/disk-io.c
fs/btrfs/extent_io.c
fs/btrfs/extent_io.h
fs/btrfs/send.c
fs/btrfs/transaction.c
fs/btrfs/transaction.h