[GIT PULL] Smaller btrfs pull

[GIT PULL] Smaller btrfs pull

[Chris Mason]

Hi Linus,

I reworked my trees to remove the cleanups and a few of the fixes that
were doing larger surgery.  This cut the pull in half, and I've pushed
it out to my integration branch.

Almost all of them are fit for an rc2 or rc3, so I've shelved most of it
for later.  I'll go through again and rip a few more of them out for
the next merge window.

I also rebased and retested 9 of these that I'd like to see in
sooner.  They are all fixes I'd like to get out to a broader audience.

The biggest of the bunch is Mark's quota fix, which is also in the SUSE
kernel, and makes our subvolume quotas dramatically more accurate.

I've been running xfstests with these against your current git
overnight, but I'm queueing up longer tests as well.  I understand
you may want to wait until rc2, but either way I'll get a sane queue
into my linux-next branch for the rest of the rcs.

These are all in my for-linus2 branch:

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

Chris Mason (1) commits (+6/-267):
    btrfs: disable strict file flushes for renames and truncates

David Sterba (1) commits (+45/-6):
    btrfs: adjust statfs calculations according to raid profiles

Filipe Manana (2) commits (+4/-1):
    Btrfs: fix csum tree corruption, duplicate and outdated checksums
    Btrfs: read lock extent buffer while walking backrefs

Josef Bacik (1) commits (+23/-25):
    Btrfs: __btrfs_mod_ref should always use no_quota

Liu Bo (1) commits (+12/-0):
    Btrfs: fix compressed write corruption on enospc

Mark Fasheh (2) commits (+435/-4):
    btrfs: qgroup: account shared subtrees during snapshot delete
    btrfs: correctly handle return from ulist_add

Takashi Iwai (1) commits (+20/-6):
    Btrfs: Fix memory corruption by ulist_add_merge() on 32bit arch

Total: (9) commits

 fs/btrfs/backref.c      |  14 ++-
 fs/btrfs/btrfs_inode.h  |   6 -
 fs/btrfs/ctree.c        |  20 ++--
 fs/btrfs/ctree.h        |   4 +-
 fs/btrfs/disk-io.c      |  32 ------
 fs/btrfs/extent-tree.c  | 285 +++++++++++++++++++++++++++++++++++++++++++++---
 fs/btrfs/file-item.c    |   2 +-
 fs/btrfs/file.c         |  26 +----
 fs/btrfs/inode.c        |  59 +++-------
 fs/btrfs/ordered-data.c | 123 ---------------------
 fs/btrfs/ordered-data.h |   5 -
 fs/btrfs/qgroup.c       | 169 ++++++++++++++++++++++++++++
 fs/btrfs/qgroup.h       |   1 +
 fs/btrfs/super.c        |  51 ++++++++-
 fs/btrfs/transaction.c  |  33 +-----
 fs/btrfs/transaction.h  |   1 -
 fs/btrfs/ulist.h        |  15 +++
 17 files changed, 541 insertions(+), 305 deletions(-)

Re: [GIT PULL] Smaller btrfs pull

[Linus Torvalds]

On Fri, Aug 15, 2014 at 11:26 AM, Chris Mason <clm@fb.com> wrote:
>
> I've been running xfstests with these against your current git
> overnight, but I'm queueing up longer tests as well.  I understand
> you may want to wait until rc2, but either way I'll get a sane queue
> into my linux-next branch for the rest of the rcs.

You completely mis-understand.

If something isn't appropriate for the merge window, then it sure as
HELL isn't appropriate for later rc's either.

So I'm not going to pull some "stragglers" later and just pull some
initial stuff now. That's not how this works.

The changes for the merge window should have been ready *before* the
merge window even opened. That has always been the rule. We don't do
random development and re-organization during the merge window, and we
certainly do not do it *later*.

I'm going to pull this reduced set, but that in no way means that I
will then pull later sets after the merge window.  The stuff after the
merge window should be pure fixes, and I'm in fact going to be
stricter with btrfs than usual, because I think this was such a
disaster. Oopses, regressions, data corruption, security fixes, and
things like that *only*. No cleanups, no random crap, nothing that
doesn't count as critical.

               Linus

Re: [GIT PULL] Smaller btrfs pull

[Chris Mason]

On 08/16/2014 11:11 AM, Linus Torvalds wrote:
> On Fri, Aug 15, 2014 at 11:26 AM, Chris Mason <clm@fb.com> wrote:
>>
>> I've been running xfstests with these against your current git
>> overnight, but I'm queueing up longer tests as well.  I understand
>> you may want to wait until rc2, but either way I'll get a sane queue
>> into my linux-next branch for the rest of the rcs.
> 
> You completely mis-understand.
> 
> If something isn't appropriate for the merge window, then it sure as
> HELL isn't appropriate for later rc's either.
> 
> So I'm not going to pull some "stragglers" later and just pull some
> initial stuff now. That's not how this works.

Hi Linus,

Sorry that I wasn't clear.  I had already pushed 1/2 of the commits off
to the 3.18 merge window.  Of the remaining commits, my plan was to send
the fixes that would qualify for rc2 or rc3 during those rcs.

I was trying to say that I fully expected these patches to be closely
inspected.  I'll bring my white gloves.

-chris