Skip to contentSkip to conversation

Btrfs updates

GIT PULL Chris Mason 4 participants 5 messages Jun 12, 2011 – Jun 13, 2011 Btrfs file system

lore
Share & tools
lore

Chris Mason

author
#0 lore raw

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(-)
#1 lore raw
Quoted 2 lines · Chris Mason

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

#2 lore raw
In reply to Chris Mason
Quoted 5 lines · Chris Mason

Hi everyone,

The for-linus branch of the btrfs unstable tree:

git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.gi=

t for-linus

Quoted 2 lines

Has our current queue of fixes. Josef's is the biggest pile, mostly =

in

Quoted 2 lines

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

Quoted 1 line

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: =E2=80=98btrfs_root_attrs=E2=80=99 define= d but not used
fs/btrfs/sysfs.c:97: warning: =E2=80=98btrfs_super_attrs=E2=80=99 defin= ed but not used
fs/btrfs/sysfs.c:153: warning: =E2=80=98btrfs_super_release=E2=80=99 de= fined but not used =20
fs/btrfs/sysfs.c:160: warning: =E2=80=98btrfs_root_release=E2=80=99 def= ined 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

--=20
[email protected] -- Speaking for myself only

author
#3 lore raw

Excerpts from Andi Kleen's message of 2011-06-12 21:02:54 -0400:

Quoted 7 lines

Chris Mason <[email protected]> writes:
=20

Quoted 5 lines

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

Quoted 3 lines

=20

Quoted 2 lines

Has our current queue of fixes. Josef's is the biggest pile, mostl=

y in

Quoted 1 line
Quoted 1 line

the allocator. Josef and I both managed to merge his patch to avoi=

d

Quoted 1 line
Quoted 1 line

mapping the extent buffer if skip_locking was set, git merge is jus=

t a

Quoted 5 lines
Quoted 1 line

little too easy sometimes (I double checked the resulting code).

=20
The new in 3.0 btrfs warnings on every build are still there:
=20
fs/btrfs/sysfs.c:76: warning: =E2=80=98btrfs_root_attrs=E2=80=99 defi=

ned but not used

Quoted 1 line

fs/btrfs/sysfs.c:97: warning: =E2=80=98btrfs_super_attrs=E2=80=99 def=

ined but not used

Quoted 1 line

fs/btrfs/sysfs.c:153: warning: =E2=80=98btrfs_super_release=E2=80=99 =

defined but not used =20

Quoted 1 line

fs/btrfs/sysfs.c:160: warning: =E2=80=98btrfs_root_release=E2=80=99 d=

efined but not used

Quoted 6 lines

=20
These are not even used inside any ifdef. It's unclear to me: were these supposed to be used or removed?
=20
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 ri= p
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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#4 lore raw
In reply to Andi Kleen
Quoted 27 lines · Andi Kleen
Quoted 11 lines · Chris Mason

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?