1. 18 May, 2013 21 commits
  2. 17 May, 2013 2 commits
  3. 07 May, 2013 2 commits
  4. 06 May, 2013 15 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
    • David Sterba's avatar
      f7a52a40
    • David Sterba's avatar
      34c2b290
    • Eric Sandeen's avatar
      btrfs: make static code static & remove dead code · 48a3b636
      Eric Sandeen authored
      Big patch, but all it does is add statics to functions which
      are in fact static, then remove the associated dead-code fallout.
      
      removed functions:
      
      btrfs_iref_to_path()
      __btrfs_lookup_delayed_deletion_item()
      __btrfs_search_delayed_insertion_item()
      __btrfs_search_delayed_deletion_item()
      find_eb_for_page()
      btrfs_find_block_group()
      range_straddles_pages()
      extent_range_uptodate()
      btrfs_file_extent_length()
      btrfs_scrub_cancel_devid()
      btrfs_start_transaction_lflush()
      
      btrfs_print_tree() is left because it is used for debugging.
      btrfs_start_transaction_lflush() and btrfs_reada_detach() are
      left for symmetry.
      
      ulist.c functions are left, another patch will take care of those.
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      48a3b636
    • Josef Bacik's avatar
      Btrfs: deal with errors in write_dev_supers · 634554dc
      Josef Bacik authored
      If you try to mount -o loop a restored file system it will panic if the file
      ends up being smaller than the original disk.  This is because we go to try and
      get a block for a super that may be past the EOF which makes __getblk return
      NULL for a buffer head when we aren't expecting it to.  Fix this by dealing with
      this case and just jacking up the errors count.  With this patch we no longer
      panic when mounting a restored file system loopback.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      634554dc
    • Josef Bacik's avatar
      Btrfs: remove almost all of the BUG()'s from tree-log.c · 3650860b
      Josef Bacik authored
      There were a whole bunch and I was doing it for other things.  I haven't tested
      these error paths but at the very least this is better than panicing.  I've only
      left 2 BUG_ON()'s since they are logic errors and I want to replace them with a
      ASSERT framework that we can compile out for production users.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      3650860b
    • Josef Bacik's avatar
      Btrfs: deal with free space cache errors while replaying log · b50c6e25
      Josef Bacik authored
      So everybody who got hit by my fsync bug will still continue to hit this
      BUG_ON() in the free space cache, which is pretty heavy handed.  So I took a
      file system that had this bug and fixed up all the BUG_ON()'s and leaks that
      popped up when I tried to mount a broken file system like this.  With this patch
      we just fail to mount instead of panicing.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      b50c6e25
    • Jan Schmidt's avatar
      Btrfs: automatic rescan after "quota enable" command · 3d7b5a28
      Jan Schmidt authored
      When qgroup tracking is enabled, we do an automatic cycle of the new rescan
      mechanism.
      Signed-off-by: default avatarJan Schmidt <list.btrfs@jan-o-sch.net>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      3d7b5a28
    • Jan Schmidt's avatar
      Btrfs: rescan for qgroups · 2f232036
      Jan Schmidt authored
      If qgroup tracking is out of sync, a rescan operation can be started. It
      iterates the complete extent tree and recalculates all qgroup tracking data.
      This is an expensive operation and should not be used unless required.
      
      A filesystem under rescan can still be umounted. The rescan continues on the
      next mount.  Status information is provided with a separate ioctl while a
      rescan operation is in progress.
      Signed-off-by: default avatarJan Schmidt <list.btrfs@jan-o-sch.net>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      2f232036
    • Jan Schmidt's avatar
      Btrfs: split btrfs_qgroup_account_ref into four functions · 46b665ce
      Jan Schmidt authored
      The function is separated into a preparation part and the three accounting
      steps mentioned in the qgroups documentation. The goal is to make steps two
      and three usable by the rescan functionality. A side effect is that the
      function is restructured into readable subunits.
      Signed-off-by: default avatarJan Schmidt <list.btrfs@jan-o-sch.net>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      46b665ce
    • Miao Xie's avatar
      Btrfs: allocate new chunks if the space is not enough for global rsv · 3c76cd84
      Miao Xie authored
      When running the 208th of xfstests, the fs returned the enospc
      error when there was lots of free space in the disk.
      
      By bisect debug, we found it was introduced by commit 96f1bb57.
      This commit makes the space check for the global reservation in
      can_overcommit() be inconsistent with should_alloc_chunk().
      can_overcommit() requires that the free space is 2 times the size
      of the global reservation, or we can't do overcommit. And instead,
      we need reclaim some reserved space, and if we still don't have
      enough free space, we need allocate a new chunk. But unfortunately,
      should_alloc_chunk() just requires that the free space is 1 time
      the size of the global reservation, that is we would not try to
      allocate a new chunk if the free space size is in the middle of
      these two requires, and just return the enospc error. Fix it.
      
      Cc: Jim Schutt <jaschut@sandia.gov>
      Cc: Josef Bacik <jbacik@fusionio.com>
      Signed-off-by: default avatarMiao Xie <miaox@cn.fujitsu.com>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      3c76cd84
    • Jan Schmidt's avatar
      Btrfs: separate sequence numbers for delayed ref tracking and tree mod log · fc36ed7e
      Jan Schmidt authored
      Sequence numbers for delayed refs have been introduced in the first version
      of the qgroup patch set. To solve the problem of find_all_roots on a busy
      file system, the tree mod log was introduced. The sequence numbers for that
      were simply shared between those two users.
      
      However, at one point in qgroup's quota accounting, there's a statement
      accessing the previous sequence number, that's still just doing (seq - 1)
      just as it would have to in the very first version.
      
      To satisfy that requirement, this patch makes the sequence number counter 64
      bit and splits it into a major part (used for qgroup sequence number
      counting) and a minor part (incremented for each tree modification in the
      log). This enables us to go exactly one major step backwards, as required
      for qgroups, while still incrementing the sequence counter for tree mod log
      insertions to keep track of their order. Keeping them in a single variable
      means there's no need to change all the code dealing with comparisons of two
      sequence numbers.
      
      The sequence number is reset to 0 on commit (not new in this patch), which
      ensures we won't overflow the two 32 bit counters.
      
      Without this fix, the qgroup tracking can occasionally go wrong and WARN_ONs
      from the tree mod log code may happen.
      Signed-off-by: default avatarJan Schmidt <list.btrfs@jan-o-sch.net>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      fc36ed7e