Hi everyone,
The for-linus branch of the btrfs unstable tree:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git for-linus
Has our current queue of fixes. Josef's is the biggest pile, mostly in
the allocator. Josef and I both managed to merge his patch to avoid
mapping the extent buffer if skip_locking was set, git merge is just a
little too easy sometimes (I double checked the resulting code).
We've also got some fixes for the new scrub code, and a regression fix
for the new use of current->journal_info in nested transactions.
Josef Bacik (9) commits (+178/-65):
Btrfs: don't commit the transaction if we dont have enough pinned bytes (+7/-0)
Btrfs: don't map extent buffer if path->skip_locking is set (+7/-3)
Btrfs: cache bitmaps when searching for a cluster (+49/-5)
Btrfs: noinline the cluster searching functions (+10/-8)
Btrfs: unlock the trans lock properly (+1/-1)
Btrfs: fix the allocator loop logic (+25/-23)
Btrfs: fix duplicate checking logic (+3/-3)
Btrfs: fix bitmap regression (+69/-19)
Arne Jansen (3) commits (+39/-32):
btrfs: remove unneeded includes from scrub.c (+0/-6)
btrfs: scrub: errors in tree enumeration (+34/-23)
btrfs: reinitialize scrub workers (+5/-3)
Li Zefan (2) commits (+15/-10):
Btrfs: use join_transaction in btrfs_evict_inode() (+1/-1)
Btrfs: avoid stack bloat in btrfs_ioctl_fs_info() (+14/-9)
Chris Mason (1) commits (+5/-4):
Btrfs: make sure to recheck for bitmaps in clusters
Sage Weil (1) commits (+4/-1):
Btrfs: clear current->journal_info on async transaction commit
Ilya Dryomov (1) commits (+2/-6):
Btrfs - use %pU to print fsid
Jan Schmidt (1) commits (+1/-1):
Btrfs: fix extent state leak on failed nodatasum reads
David Sterba (1) commits (+1/-2):
btrfs: fix unlocked access of delalloc_inodes
richard kennedy (1) commits (+1/-1):
btrfs: remove 64bit alignment padding to allow extent_buffer to fit into one fewer cacheline
Total: (20) commits (+246/-122)
fs/btrfs/ctree.c | 10 ++-
fs/btrfs/disk-io.c | 5 +-
fs/btrfs/extent-tree.c | 55 +++++++++------
fs/btrfs/extent_io.h | 2 +-
fs/btrfs/free-space-cache.c | 163 ++++++++++++++++++++++++++++++++++---------
fs/btrfs/inode.c | 4 +-
fs/btrfs/ioctl.c | 23 ++++---
fs/btrfs/scrub.c | 69 ++++++++++--------
fs/btrfs/transaction.c | 7 ++-
fs/btrfs/volumes.c | 8 +--
10 files changed, 233 insertions(+), 113 deletions(-)
On Sun, Jun 12, 2011 at 4:57 AM, Chris Mason <[email protected]> wrote:
>
> The for-linus branch of the btrfs unstable tree:
Chris, this is getting ridiculous.
You guys need to start honoring the merge window. None of these big
pulls afterwards. If the code wasn't ready, it damn well shouldn't
have been pushed to me in the first place.
I pulled this round, but next pull request had better make it very
clear that it's only minimal *regression* fixes. Nothing more.
Linus
Chris Mason <[email protected]> writes:
> Hi everyone,
>
> The for-linus branch of the btrfs unstable tree:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git for-linus
>
> Has our current queue of fixes. Josef's is the biggest pile, mostly in
> the allocator. Josef and I both managed to merge his patch to avoid
> mapping the extent buffer if skip_locking was set, git merge is just a
> little too easy sometimes (I double checked the resulting code).
The new in 3.0 btrfs warnings on every build are still there:
fs/btrfs/sysfs.c:76: warning: ‘btrfs_root_attrs’ defined but not used
fs/btrfs/sysfs.c:97: warning: ‘btrfs_super_attrs’ defined but not used
fs/btrfs/sysfs.c:153: warning: ‘btrfs_super_release’ defined but not used
fs/btrfs/sysfs.c:160: warning: ‘btrfs_root_release’ defined but not used
These are not even used inside any ifdef. It's unclear to me: were
these supposed to be used or removed?
Probably better to remove since they seem to be untested, unless
it was a merge error?
-Andi
--
[email protected] -- Speaking for myself only
Excerpts from Andi Kleen's message of 2011-06-12 21:02:54 -0400:
> Chris Mason <[email protected]> writes:
>
> > Hi everyone,
> >
> > The for-linus branch of the btrfs unstable tree:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git for-linus
>
> >
> > Has our current queue of fixes. Josef's is the biggest pile, mostly in
> > the allocator. Josef and I both managed to merge his patch to avoid
> > mapping the extent buffer if skip_locking was set, git merge is just a
> > little too easy sometimes (I double checked the resulting code).
>
> The new in 3.0 btrfs warnings on every build are still there:
>
> fs/btrfs/sysfs.c:76: warning: ‘btrfs_root_attrs’ defined but not used
> fs/btrfs/sysfs.c:97: warning: ‘btrfs_super_attrs’ defined but not used
> fs/btrfs/sysfs.c:153: warning: ‘btrfs_super_release’ defined but not used
> fs/btrfs/sysfs.c:160: warning: ‘btrfs_root_release’ defined but not used
>
> These are not even used inside any ifdef. It's unclear to me: were
> these supposed to be used or removed?
>
> Probably better to remove since they seem to be untested, unless
> it was a merge error?
Right, I've been trying to decide how much of the sysfs interface to rip
out. We're not using it the way I had planned to, and Kay's proposed
udev changes are better than my original plans for sysfs.
One way or another I'll kill these off in the next rc.
-chris
09:02, Andi Kleen wrote:
> Chris Mason <[email protected]> writes:
>
>> Hi everyone,
>>
>> The for-linus branch of the btrfs unstable tree:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git for-linus
>
>>
>> Has our current queue of fixes. Josef's is the biggest pile, mostly in
>> the allocator. Josef and I both managed to merge his patch to avoid
>> mapping the extent buffer if skip_locking was set, git merge is just a
>> little too easy sometimes (I double checked the resulting code).
>
> The new in 3.0 btrfs warnings on every build are still there:
>
> fs/btrfs/sysfs.c:76: warning: ‘btrfs_root_attrs’ defined but not used
> fs/btrfs/sysfs.c:97: warning: ‘btrfs_super_attrs’ defined but not used
> fs/btrfs/sysfs.c:153: warning: ‘btrfs_super_release’ defined but not used
> fs/btrfs/sysfs.c:160: warning: ‘btrfs_root_release’ defined but not used
>
> These are not even used inside any ifdef. It's unclear to me: were
> these supposed to be used or removed?
>
> Probably better to remove since they seem to be untested, unless
> it was a merge error?
>