2012-08-09 15:50:37

by Chris Mason

[permalink] [raw]
Subject: [GIT PULL 1/2] Btrfs fixes

Hi everyone,

This first pull is the bulk of our changes for the next rc. It is
against the 3.5 kernel so people testing the new features have a stable
point to work against. This was tested against Linus' current tree as
well.

The second pull is just one fix against 3.6-rc1 (in another email).

Linus, please grab my for-linus branch:

git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus

Most of these fixes are against the new send/receive code. Alexander
fixed a number of bugs in there and I found a more while backing up my
laptop. It does nightly incremental runs now about 3x faster than
rsync, so things are looking pretty good.

On top of that we have fixes for some long standing bugs in the delayed
reference code (a few more of these are still being worked on),
deadlocks and other small fixes.

Alexander Block (23) commits (+482/-419):
Btrfs: don't treat top/root directory inode as deleted/reused (+20/-1)
Btrfs: fix use of radix_tree for name_cache in send/receive (+37/-39)
Btrfs: rename backref_ctx::found_in_send_root to found_itself (+4/-4)
Btrfs: pass root instead of parent_root to iterate_inode_ref (+2/-2)
Btrfs: add correct parent to check_dirs when dir got moved (+11/-0)
Btrfs: add missing check for dir != tmp_dir to is_first_ref (+1/-1)
Btrfs: fix check for changed extent in is_extent_unchanged (+2/-2)
Btrfs: free nce and nce_head on error in name_cache_insert (+5/-1)
Btrfs: don't break in the final loop of find_extent_clone (+0/-1)
Btrfs: fix cur_ino < parent_ino case for send/receive (+146/-244)
Btrfs: add/fix comments/documentation for send/receive (+134/-6)
Btrfs: use normal return path for root == send_root case (+0/-6)
Btrfs: fix memory leak for name_cache in send/receive (+1/-0)
Btrfs: use kmalloc instead of stack for backref_ctx (+18/-11)
Btrfs: remove unused use_list from send/receive code (+0/-2)
Btrfs: remove unused tmp_path from iterate_dir_item (+0/-8)
Btrfs: add rdev to get_inode_info in send/receive (+17/-13)
Btrfs: use <= instead of < in is_extent_unchanged (+1/-1)
Btrfs: update send_progress at correct places (+20/-6)
Btrfs: ignore non-FS inodes for send/receive (+5/-0)
Btrfs: code cleanups for send/receive (+35/-48)
Btrfs: make aux field of ulist 64 bit (+21/-23)
Btrfs: remove unused code with #if 0 (+2/-0)

Josef Bacik (9) commits (+325/-215):
Btrfs: don't allocate a seperate csums array for direct reads (+19/-32)
Btrfs: do not use missing devices when showing devname (+2/-0)
Btrfs: fix enospc problems when deleting a subvol (+1/-1)
Btrfs: increase the size of the free space cache (+7/-8)
Btrfs: lock extents as we map them in DIO (+127/-129)
Btrfs: allow delayed refs to be merged (+142/-27)
Btrfs: do not strdup non existent strings (+5/-3)
Btrfs: barrier before waitqueue_active (+10/-12)
Btrfs: use a slab for btrfs_dio_private (+12/-3)

Dan Carpenter (4) commits (+16/-8):
Btrfs: unlock on error in btrfs_delalloc_reserve_metadata() (+3/-1)
Btrfs: fix some error codes in btrfs_qgroup_inherit() (+6/-2)
Btrfs: fix some endian bugs handling the root times (+4/-4)
Btrfs: checking for NULL instead of IS_ERR (+3/-1)

Stefan Behrens (3) commits (+8/-36):
Btrfs: fix a misplaced address operator in a condition (+1/-1)
Btrfs: remove superblock writing after fatal error (+5/-33)
Btrfs: fix that error value is changed by mistake (+2/-2)

Chris Mason (2) commits (+40/-15):
Btrfs: fix btrfs send for inline items and compression (+37/-15)
Btrfs: don't run __tree_mod_log_free_eb on leaves (+3/-0)

Fengguang Wu (2) commits (+4/-6):
btrfs: fix second lock in btrfs_delete_delayed_items() (+3/-2)
btrfs: Use PTR_RET in btrfs_resume_balance_async() (+1/-4)

Arne Jansen (2) commits (+38/-73):
Btrfs: fix deadlock in wait_for_more_refs (+21/-73)
Btrfs: fix race in run_clustered_refs (+17/-0)

Miao Xie (1) commits (+1/-0):
Btrfs: fix wrong mtime and ctime when creating snapshots

Total: (46) commits

fs/btrfs/backref.c | 12 +-
fs/btrfs/compression.c | 1 +
fs/btrfs/ctree.c | 14 +-
fs/btrfs/ctree.h | 3 +-
fs/btrfs/delayed-inode.c | 12 +-
fs/btrfs/delayed-ref.c | 163 +++++++--
fs/btrfs/delayed-ref.h | 4 +
fs/btrfs/disk-io.c | 45 +--
fs/btrfs/disk-io.h | 2 +-
fs/btrfs/extent-tree.c | 123 +++----
fs/btrfs/extent_io.c | 1 -
fs/btrfs/file-item.c | 4 +-
fs/btrfs/inode.c | 318 ++++++++---------
fs/btrfs/ioctl.c | 2 +-
fs/btrfs/locking.c | 2 +-
fs/btrfs/qgroup.c | 32 +-
fs/btrfs/root-tree.c | 4 +-
fs/btrfs/send.c | 895 ++++++++++++++++++++++++++---------------------
fs/btrfs/super.c | 2 +
fs/btrfs/transaction.c | 3 +-
fs/btrfs/ulist.c | 7 +-
fs/btrfs/ulist.h | 9 +-
fs/btrfs/volumes.c | 16 +-
23 files changed, 908 insertions(+), 766 deletions(-)


2012-08-21 01:56:25

by Linus Torvalds

[permalink] [raw]
Subject: Re: [GIT PULL 1/2] Btrfs fixes

On Mon, Aug 20, 2012 at 6:53 PM, Chris Samuel <[email protected]> wrote:
>
> This pull request with a whole heap of btrfs fixes (46 commits) appears
> not to have been merged yet, does anyone know if it was rejected or just
> missed ?

Read my -rc2 release notes.

TL;DR: I rejected big pull requests that didn't convince me. Make a
damn good case for it, or send minimal fixes instead.

I'm tried of these "oops, what we sent you for -rc1 wasn't ready, so
here's a thousand lines of changes" crap.

Linus

2012-08-21 02:03:42

by Chris Samuel

[permalink] [raw]
Subject: Re: [GIT PULL 1/2] Btrfs fixes

On 10/08/12 01:50, Chris Mason wrote:

> Hi everyone,
>
> This first pull is the bulk of our changes for the next rc. It is
> against the 3.5 kernel so people testing the new features have a stable
> point to work against. This was tested against Linus' current tree as
> well.
[...]

This pull request with a whole heap of btrfs fixes (46 commits) appears
not to have been merged yet, does anyone know if it was rejected or just
missed ?

cheers,
Chris
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC

2012-08-21 03:23:39

by Chris Samuel

[permalink] [raw]
Subject: Re: [GIT PULL 1/2] Btrfs fixes

On 21/08/12 11:55, Linus Torvalds wrote:

> Read my -rc2 release notes.

Ahh, thanks (I'm not on LKML so didn't see those).

> TL;DR: I rejected big pull requests that didn't convince me. Make a
> damn good case for it, or send minimal fixes instead.

Can't argue with that!

> I'm tried of these "oops, what we sent you for -rc1 wasn't ready, so
> here's a thousand lines of changes" crap.

I can understand that with respect to the send/recv stuff, so it's
really down to Chris Mason to extract just the fixes to problems that
are in 3.5 and earlier and submit just those instead.

All the best,
Chris
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC

2012-08-21 13:10:21

by Chris Mason

[permalink] [raw]
Subject: Re: [GIT PULL 1/2] Btrfs fixes

On Mon, Aug 20, 2012 at 07:55:59PM -0600, Linus Torvalds wrote:
> On Mon, Aug 20, 2012 at 6:53 PM, Chris Samuel <[email protected]> wrote:
> >
> > This pull request with a whole heap of btrfs fixes (46 commits) appears
> > not to have been merged yet, does anyone know if it was rejected or just
> > missed ?
>
> Read my -rc2 release notes.
>
> TL;DR: I rejected big pull requests that didn't convince me. Make a
> damn good case for it, or send minimal fixes instead.
>
> I'm tried of these "oops, what we sent you for -rc1 wasn't ready, so
> here's a thousand lines of changes" crap.

When just the second pull went in, I wasn't sure if it was waiting for
vacation or you felt it was too big, but when I saw rc2 it was pretty
clear.

So I'm working up an rc3 pull with longer explanations. The bulk of my
last pull was send/receive fixes. The rc1 send/recv worked fine for me
on my test box, but larger scale use on well aged filesystems showed
some problems.

It's fair to say send/receive wasn't ready. I did expect some fixes for
rc2 but not that many. More details will be in my pull this afternoon,
but with our current code it is working very well for me.

-chris