1. 24 Jan, 2013 4 commits
    • Josef Bacik's avatar
      Btrfs: put csums on the right ordered extent · e58dd74b
      Josef Bacik authored
      I noticed a WARN_ON going off when adding csums because we were going over
      the amount of csum bytes that should have been allowed for an ordered
      extent.  This is a leftover from when we used to hold the csums privately
      for direct io, but now we use the normal ordered sum stuff so we need to
      make sure and check if we've moved on to another extent so that the csums
      are added to the right extent.  Without this we could end up with csums for
      bytenrs that don't have extents to cover them yet.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
    • Liu Bo's avatar
      Btrfs: use right range to find checksum for compressed extents · 192000dd
      Liu Bo authored
      For compressed extents, the range of checksum is covered by disk length,
      and the disk length is different with ram length, so we need to use disk
      length instead to get us the right checksum.
      Signed-off-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
    • Josef Bacik's avatar
      Btrfs: fix panic when recovering tree log · b0175117
      Josef Bacik authored
      A user reported a BUG_ON(ret) that occured during tree log replay.  Ret was
      -EAGAIN, so what I think happened is that we removed an extent that covered
      a bitmap entry and an extent entry.  We remove the part from the bitmap and
      return -EAGAIN and then search for the next piece we want to remove, which
      happens to be an entire extent entry, so we just free the sucker and return.
      The problem is ret is still set to -EAGAIN so we trip the BUG_ON().  The
      user used btrfs-zero-log so I'm not 100% sure this is what happened so I've
      added a WARN_ON() to catch the other possibility.  Thanks,
      Reported-by: default avatarJan Steffens <jan.steffens@gmail.com>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
    • Josef Bacik's avatar
      Btrfs: do not allow logged extents to be merged or removed · 201a9038
      Josef Bacik authored
      We drop the extent map tree lock while we're logging extents, so somebody
      could come in and merge another extent into this one and screw up our
      logging, or they could even remove us from the list which would keep us from
      logging the extent or freeing our ref on it, so we need to make sure to not
      clear LOGGING until after the extent is logged, and then we can merge it to
      adjacent extents.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
  2. 22 Jan, 2013 5 commits
  3. 20 Jan, 2013 5 commits
  4. 14 Jan, 2013 14 commits
  5. 19 Dec, 2012 1 commit
  6. 18 Dec, 2012 1 commit
  7. 17 Dec, 2012 10 commits