Re: [GIT PULL] Btrfs updates for 2.6.29-rc

[Chris Mason]

On Fri, 2009-02-06 at 13:59 -0800, Linus Torvalds wrote:
> 
> On Fri, 6 Feb 2009, Chris Mason wrote:
> >
> >  18 files changed, 996 insertions(+), 134 deletions(-)
> 
> This is not at all what I get. I get
> 
>  27 files changed, 1421 insertions(+), 451 deletions(-)
> 
> so there is some confusion there.

Crud, the confusion would be me.  I missed the cleanups and bug fixes
between 2.6.29-rc1 and rc3.   The correct diffstat and short log are
below, and the only non-btrfs change is to the MAINTAINERS file.

MAINTAINERS             |    8
 fs/btrfs/Kconfig        |   13 +
 fs/btrfs/async-thread.c |   61 +++++-
 fs/btrfs/compression.c  |    1
 fs/btrfs/ctree.c        |  276 ++++++++++++++++++++++++++----
 fs/btrfs/ctree.h        |   28 +--
 fs/btrfs/disk-io.c      |  120 +++++++++----
 fs/btrfs/disk-io.h      |    2
 fs/btrfs/extent-tree.c  |  438 ++++++++++++++++++++++++++++++++++++++++--------
 fs/btrfs/extent_io.c    |  132 +++++++++++---
 fs/btrfs/extent_io.h    |   18 +
 fs/btrfs/extent_map.c   |    1
 fs/btrfs/file.c         |    5
 fs/btrfs/inode.c        |   84 +++++++--
 fs/btrfs/ioctl.c        |    1
 fs/btrfs/locking.c      |  208 ++++++++++++++++++++--
 fs/btrfs/locking.h      |    6
 fs/btrfs/ordered-data.c |    4
 fs/btrfs/ref-cache.c    |    1
 fs/btrfs/ref-cache.h    |    1
 fs/btrfs/super.c        |    6
 fs/btrfs/transaction.c  |    4
 fs/btrfs/tree-defrag.c  |    1
 fs/btrfs/tree-log.c     |  354 ++++++++++++++++++--------------------
 fs/btrfs/volumes.c      |   49 ++---
 fs/btrfs/xattr.c        |   48 ++++-
 fs/btrfs/xattr.h        |    2
 27 files changed, 1421 insertions(+), 451 deletions(-)

Chris Ball (1):
      Btrfs: Handle SGID bit when creating inodes

Chris Mason (19):
      Btrfs: stop providing a bmap operation to avoid swapfile corruptions
      Btrfs: do less aggressive btree readahead
      Merge branch 'master' of git://git.kernel.org/.../mason/btrfs-unstable
      Btrfs: fix readdir on 32 bit machines
      Btrfs: Catch missed bios in the async bio submission thread
      Btrfs: async threads should try harder to find work
      Btrfs: sort references by byte number during btrfs_inc_ref
      Btrfs: disable leak debugging checks in extent_io.c
      Btrfs: hash_lock is no longer needed
      Btrfs: Change btree locking to use explicit blocking points
      Btrfs: Make btrfs_drop_snapshot work in larger and more efficient chunks
      Btrfs: Don't try to compress pages past i_size
      Btrfs: Change btrfs_truncate_inode_items to stop when it hits the inode
      Btrfs: change btrfs_del_leaf to drop locks earlier
      Btrfs: fix btrfs_unlock_up_safe to walk the entire path
      Btrfs: Only prep for btree deletion balances when nodes are mostly empty
      Btrfs: don't return congestion in write_cache_pages as often
      Btrfs: Fix memory leak in cache_drop_leaf_ref
      Btrfs: Make sure dir is non-null before doing S_ISGID checks

Christian Hesse (1):
      Btrfs: make btrfs acls selectable

Huang Weiyi (2):
      Btrfs: removed unused #include <version.h>'s
      Btrfs: remove duplicated #include

Jan Engelhardt (1):
      Btrfs: change/remove typedef

Jim Owens (1):
      Btrfs: selinux support

Joe Perches (1):
      Btrfs: MAINTAINERS entry

Josef Bacik (2):
      Btrfs: cleanup xattr code
      Btrfs: join the transaction in __btrfs_setxattr

Qinghuang Feng (3):
      Btrfs: check return value for kthread_run() correctly
      Btrfs: simplify iteration codes
      Btrfs: open_ctree() error handling can oops on fs_info

Roland Dreier (1):
      Btrfs: Remove extra KERN_INFO in the middle of a line

Wang Cong (1):
      Btrfs: cleanup fs/btrfs/super.c::btrfs_control_ioctl()

Yan Zheng (4):
      Btrfs: fix locking issue in btrfs_remove_block_group
      Btrfs: Fix infinite loop in btrfs_extent_post_op
      Btrfs: fix stop searching test in replace_one_extent
      Btrfs: fix tree logs parallel sync

Yehuda Sadeh (1):
      Btrfs: fiemap support



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/