1. 28 Mar, 2011 11 commits
    • Li Dongyang's avatar
      Btrfs: make btrfs_map_block() return entire free extent for each device of RAID0/1/10/DUP · fce3bb9a
      Li Dongyang authored
      btrfs_map_block() will only return a single stripe length, but we want the
      full extent be mapped to each disk when we are trimming the extent,
      so we add length to btrfs_bio_stripe and fill it if we are mapping for REQ_DISCARD.
      Signed-off-by: default avatarLi Dongyang <lidongyang@novell.com>
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      fce3bb9a
    • Li Dongyang's avatar
      Btrfs: make update_reserved_bytes() public · b4d00d56
      Li Dongyang authored
      Make the function public as we should update the reserved extents calculations
      after taking out an extent for trimming.
      Signed-off-by: default avatarLi Dongyang <lidongyang@novell.com>
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      b4d00d56
    • Mark Fasheh's avatar
      btrfs: return EXDEV when linking from different subvolumes · 3ab3564f
      Mark Fasheh authored
      btrfs_link returns EPERM if a cross-subvolume link is attempted.
      
      However, in this case I believe EXDEV to be the more appropriate value.
      >From the link(2) man page:
      
      EXDEV  oldpath and newpath are not on the same mounted file system.  (Linux
             permits a file system to be mounted at multiple points, but link()
             does not work across different mount points, even if the same file
             system is mounted on both.)
      
      This matters because an application may have different behaviors based on
      return codes.
      Signed-off-by: default avatarMark Fasheh <mfasheh@suse.com>
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      3ab3564f
    • Liu Bo's avatar
      Btrfs: Per file/directory controls for COW and compression · 75e7cb7f
      Liu Bo authored
      Data compression and data cow are controlled across the entire FS by mount
      options right now.  ioctls are needed to set this on a per file or per
      directory basis.  This has been proposed previously, but VFS developers
      wanted us to use generic ioctls rather than btrfs-specific ones.
      
      According to Chris's comment, there should be just one true compression
      method(probably LZO) stored in the super.  However, before this, we would
      wait for that one method is stable enough to be adopted into the super.
      So I list it as a long term goal, and just store it in ram today.
      
      After applying this patch, we can use the generic "FS_IOC_SETFLAGS" ioctl to
      control file and directory's datacow and compression attribute.
      
      NOTE:
       - The compression type is selected by such rules:
         If we mount btrfs with compress options, ie, zlib/lzo, the type is it.
         Otherwise, we'll use the default compress type (zlib today).
      
      v1->v2:
      - rebase to the latest btrfs.
      v2->v3:
      - fix a problem, i.e. when a file is set NOCOW via mount option, then this NOCOW
        will be screwed by inheritance from parent directory.
      Signed-off-by: default avatarLiu Bo <liubo2009@cn.fujitsu.com>
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      75e7cb7f
    • liubo's avatar
      Btrfs: add datacow flag in inode flag · 32471f6e
      liubo authored
      For datacow control, the corresponding inode flags are needed.
      This is for btrfs use.
      
      v1->v2:
      Change FS_COW_FL to another bit due to conflict with the upstream e2fsprogs
      Signed-off-by: default avatarLiu Bo <liubo2009@cn.fujitsu.com>
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      32471f6e
    • Miao Xie's avatar
      btrfs: use GFP_NOFS instead of GFP_KERNEL · fc0e4a31
      Miao Xie authored
      In the filesystem context, we must allocate memory by GFP_NOFS,
      or we may start another filesystem operation and make kswap thread hang up.
      Signed-off-by: default avatarMiao Xie <miaox@cn.fujitsu.com>
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      fc0e4a31
    • Tsutomu Itoh's avatar
      Btrfs: check return value of read_tree_block() · 97d9a8a4
      Tsutomu Itoh authored
      This patch is checking return value of read_tree_block(),
      and if it is NULL, error processing.
      Signed-off-by: default avatarTsutomu Itoh <t-itoh@jp.fujitsu.com>
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      97d9a8a4
    • David Sterba's avatar
      btrfs: properly access unaligned checksum buffer · 7e75bf3f
      David Sterba authored
      On Fri, Mar 18, 2011 at 11:56:53AM -0400, Chris Mason wrote:
      > Thanks for fielding this one.  Does put_unaligned_le32 optimize away on
      > platforms with efficient access?  It would be great if we didn't need
      > the #ifdef.
      
      (quicktest: assembly output is same for put_unaligned_le32 and direct
      assignment on my x86_64)
      I was originally following examples in
      Documentation/unaligned-memory-access.txt. From other code it seems to me that
      the define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is intended for larger
      portions of code. Macros/wrappers for {put,get}_unaligned* are chosen via
      arch/<arch>/include/asm/unaligned.h accordingly, therefore it's safe to use
      put_unaligned_le32 without the ifdef.
      
      dave
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      7e75bf3f
    • Tsutomu Itoh's avatar
      Btrfs: cleanup some BUG_ON() · db5b493a
      Tsutomu Itoh authored
      This patch changes some BUG_ON() to the error return.
      (but, most callers still use BUG_ON())
      Signed-off-by: default avatarTsutomu Itoh <t-itoh@jp.fujitsu.com>
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      db5b493a
    • liubo's avatar
      Btrfs: add initial tracepoint support for btrfs · 1abe9b8a
      liubo authored
      Tracepoints can provide insight into why btrfs hits bugs and be greatly
      helpful for debugging, e.g
                    dd-7822  [000]  2121.641088: btrfs_inode_request: root = 5(FS_TREE), gen = 4, ino = 256, blocks = 8, disk_i_size = 0, last_trans = 8, logged_trans = 0
                    dd-7822  [000]  2121.641100: btrfs_inode_new: root = 5(FS_TREE), gen = 8, ino = 257, blocks = 0, disk_i_size = 0, last_trans = 0, logged_trans = 0
       btrfs-transacti-7804  [001]  2146.935420: btrfs_cow_block: root = 2(EXTENT_TREE), refs = 2, orig_buf = 29368320 (orig_level = 0), cow_buf = 29388800 (cow_level = 0)
       btrfs-transacti-7804  [001]  2146.935473: btrfs_cow_block: root = 1(ROOT_TREE), refs = 2, orig_buf = 29364224 (orig_level = 0), cow_buf = 29392896 (cow_level = 0)
       btrfs-transacti-7804  [001]  2146.972221: btrfs_transaction_commit: root = 1(ROOT_TREE), gen = 8
         flush-btrfs-2-7821  [001]  2155.824210: btrfs_chunk_alloc: root = 3(CHUNK_TREE), offset = 1103101952, size = 1073741824, num_stripes = 1, sub_stripes = 0, type = DATA
         flush-btrfs-2-7821  [001]  2155.824241: btrfs_cow_block: root = 2(EXTENT_TREE), refs = 2, orig_buf = 29388800 (orig_level = 0), cow_buf = 29396992 (cow_level = 0)
         flush-btrfs-2-7821  [001]  2155.824255: btrfs_cow_block: root = 4(DEV_TREE), refs = 2, orig_buf = 29372416 (orig_level = 0), cow_buf = 29401088 (cow_level = 0)
         flush-btrfs-2-7821  [000]  2155.824329: btrfs_cow_block: root = 3(CHUNK_TREE), refs = 2, orig_buf = 20971520 (orig_level = 0), cow_buf = 20975616 (cow_level = 0)
       btrfs-endio-wri-7800  [001]  2155.898019: btrfs_cow_block: root = 5(FS_TREE), refs = 2, orig_buf = 29384704 (orig_level = 0), cow_buf = 29405184 (cow_level = 0)
       btrfs-endio-wri-7800  [001]  2155.898043: btrfs_cow_block: root = 7(CSUM_TREE), refs = 2, orig_buf = 29376512 (orig_level = 0), cow_buf = 29409280 (cow_level = 0)
      
      Here is what I have added:
      
      1) ordere_extent:
              btrfs_ordered_extent_add
              btrfs_ordered_extent_remove
              btrfs_ordered_extent_start
              btrfs_ordered_extent_put
      
      These provide critical information to understand how ordered_extents are
      updated.
      
      2) extent_map:
              btrfs_get_extent
      
      extent_map is used in both read and write cases, and it is useful for tracking
      how btrfs specific IO is running.
      
      3) writepage:
              __extent_writepage
              btrfs_writepage_end_io_hook
      
      Pages are cirtical resourses and produce a lot of corner cases during writeback,
      so it is valuable to know how page is written to disk.
      
      4) inode:
              btrfs_inode_new
              btrfs_inode_request
              btrfs_inode_evict
      
      These can show where and when a inode is created, when a inode is evicted.
      
      5) sync:
              btrfs_sync_file
              btrfs_sync_fs
      
      These show sync arguments.
      
      6) transaction:
              btrfs_transaction_commit
      
      In transaction based filesystem, it will be useful to know the generation and
      who does commit.
      
      7) back reference and cow:
      	btrfs_delayed_tree_ref
      	btrfs_delayed_data_ref
      	btrfs_delayed_ref_head
      	btrfs_cow_block
      
      Btrfs natively supports back references, these tracepoints are helpful on
      understanding btrfs's COW mechanism.
      
      8) chunk:
      	btrfs_chunk_alloc
      	btrfs_chunk_free
      
      Chunk is a link between physical offset and logical offset, and stands for space
      infomation in btrfs, and these are helpful on tracing space things.
      
      9) reserved_extent:
      	btrfs_reserved_extent_alloc
      	btrfs_reserved_extent_free
      
      These can show how btrfs uses its space.
      Signed-off-by: default avatarLiu Bo <liubo2009@cn.fujitsu.com>
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      1abe9b8a
    • Chris Mason's avatar
      Btrfs: use RCU instead of a spinlock to protect the root node · 240f62c8
      Chris Mason authored
      The pointer to the extent buffer for the root of each tree
      is protected by a spinlock so that we can safely read the pointer
      and take a reference on the extent buffer.
      
      But now that the extent buffers are freed via RCU, we can safely
      use rcu_read_lock instead.
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      240f62c8
  2. 25 Mar, 2011 3 commits
    • Josef Bacik's avatar
      Btrfs: mark the bio with an error if we have a failure in dio · c0da7aa1
      Josef Bacik authored
      I noticed that dio_end_io calls the appropriate endio function with an error,
      but the endio functions don't actually do anything with that error, they assume
      that if there was an error then the bio will not be uptodate.  So if we had
      checksum failures we would never pass back EIO.  So if there is an error in our
      endio functions make sure to clear the uptodate flag on the bio.  Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      c0da7aa1
    • Josef Bacik's avatar
      Btrfs: don't allocate dip->csums when doing writes · 98bc3149
      Josef Bacik authored
      When doing direct writes we store the checksums in the ordered sum stuff in the
      ordered extent for writing them when the write completes, so we don't even use
      the dip->csums array.  So if we're writing, don't bother allocating dip->csums
      since we won't use it anyway.  Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      98bc3149
    • Josef Bacik's avatar
      Btrfs: cleanup how we setup free space clusters · 4e69b598
      Josef Bacik authored
      This patch makes the free space cluster refilling code a little easier to
      understand, and fixes some things with the bitmap part of it.  Currently we
      either want to refill a cluster with
      
      1) All normal extent entries (those without bitmaps)
      2) A bitmap entry with enough space
      
      The current code has this ugly jump around logic that will first try and fill up
      the cluster with extent entries and then if it can't do that it will try and
      find a bitmap to use.  So instead split this out into two functions, one that
      tries to find only normal entries, and one that tries to find bitmaps.
      
      This also fixes a suboptimal thing we would do with bitmaps.  If we used a
      bitmap we would just tell the cluster that we were pointing at a bitmap and it
      would do the tree search in the block group for that entry every time we tried
      to make an allocation.  Instead of doing that now we just add it to the clusters
      group.
      
      I tested this with my ENOSPC tests and xfstests and it survived.
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      4e69b598
  3. 21 Mar, 2011 3 commits
    • Josef Bacik's avatar
      Btrfs: don't be as aggressive about using bitmaps · 32cb0840
      Josef Bacik authored
      We have been creating bitmaps for small extents unconditionally forever.  This
      was great when testing to make sure the bitmap stuff was working, but is
      overkill normally.  So instead of always adding small chunks of free space to
      bitmaps, only start doing it if we go past half of our extent threshold.  This
      will keeps us from creating a bitmap for just one small free extent at the front
      of the block group, and will make the allocator a little faster as a result.
      Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      32cb0840
    • Josef Bacik's avatar
      Btrfs: deal with min_bytes appropriately when looking for a cluster · d0a365e8
      Josef Bacik authored
      We do all this fun stuff with min_bytes, but either don't use it in the case of
      just normal extents, or use it completely wrong in the case of bitmaps.  So fix
      this for both cases
      
      1) In the extent case, stop looking for space with window_free >= min_bytes
      instead of bytes + empty_size.
      
      2) In the bitmap case, we were looking for streches of free space that was at
      least min_bytes in size, which was not right at all.  So instead search for
      stretches of free space that are at least bytes in size (this will make a
      difference when we have > page size blocks) and then only search for min_bytes
      amount of free space.
      
      Thanks,
      Reviewed-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      d0a365e8
    • Josef Bacik's avatar
      Btrfs: check free space in block group before searching for a cluster · 7d0d2e8e
      Josef Bacik authored
      The free space cluster stuff is heavy duty, so there is no sense in going
      through the entire song and dance if there isn't enough space in the block group
      to begin with.  Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      7d0d2e8e
  4. 17 Mar, 2011 16 commits
  5. 15 Mar, 2011 1 commit
  6. 14 Mar, 2011 6 commits