v1->v2:
- I was debugging generic/484 separately because I thought it was data related,
  but it turned out to be metadata related as well, so I've added the patch
  "btrfs: call mapping_set_error() on btree inode with a write error" to the
  series.

--- Original email ---

Hello,

I saw a dmesg failure with generic/281 on our overnight runs.  This turned out
to be because we weren't getting an error back from btrfs_search_slot() even
though we found a metadata block that shouldn't have been uptodate.

The root cause is that write errors on the page clear uptodate on the page, but
not on the extent buffer itself.  Since we rely on that bit to tell wether the
extent buffer is valid or not we don't notice that the eb is bogus when we find
it in cache in a subsequent write, and eventually trip over
assert_eb_page_uptodate() warnings.

This fixes the problem I was seeing, I could easily reproduce by running
generic/281 in a loop a few times.  With these pages I haven't reproduced in 20
loops.  Thanks,

Josef

Josef Bacik (3):
  btrfs: clear extent buffer uptodate when we fail to write it
  btrfs: check the root node for uptodate before returning it
  btrfs: call mapping_set_error() on btree inode with a write error

 fs/btrfs/ctree.c     | 19 +++++++++++++++----
 fs/btrfs/extent_io.c | 14 ++++++++++++++
 2 files changed, 29 insertions(+), 4 deletions(-)