1. 14 Jun, 2013 3 commits
  2. 08 Jun, 2013 5 commits
  3. 18 May, 2013 24 commits
  4. 17 May, 2013 2 commits
  5. 07 May, 2013 2 commits
  6. 06 May, 2013 4 commits
    • David Sterba's avatar
      btrfs: fix misleading variable name for flags · b6919a58
      David Sterba authored
      The variable was named 'data' in btrfs_reserve_extent and that's the
      only function that actually uses it to let btrfs_get_alloc_profile know
      what profile we want. Then it's passed down as u64 flags.
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.cz>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      b6919a58
    • David Sterba's avatar
      41074888
    • Liu Bo's avatar
      Btrfs: improve the loop of scrub_stripe · 625f1c8d
      Liu Bo authored
      1) Right now scrub_stripe() is looping in some unnecessary cases:
      * when the found extent item's objectid has been out of the dev extent's range
        but we haven't finish scanning all the range within the dev extent
      * when all the items has been processed but we haven't finish scanning all the
        range within the dev extent
      
      In both cases, we can just finish the loop to save costs.
      
      2) Besides, when the found extent item's length is larger than the stripe
      len(64k), we don't have to release the path and search again as it'll get at the
      same key used in the last loop, we can instead increase the logical cursor in
      place till all space of the extent is scanned.
      
      3) And we use 0 as the key's offset to search btree, then get to previous item
      to find a smaller item, and again have to move to the next one to get the right
      item.  Setting offset=-1 and previous_item() is the correct way.
      
      4) As we won't find any checksum at offset unless this 'offset' is in a data
      extent, we can just find checksum when we're really going to scrub an extent.
      Signed-off-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      625f1c8d
    • David Sterba's avatar
      btrfs: read entire device info under lock · 55793c0d
      David Sterba authored
      There's a theoretical possibility of reading stale (or even more
      theoretically, freed) data from DEV_INFO ioctl when the device would
      disappear between an early mutex unlock and data being copied from the
      device structure.
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.cz>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      55793c0d