Smaller btrfs pull

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(-)

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

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