Re: [GIT PULL] Btrfs fixes for 4.6

2016-03-01 Thread Chris Mason 
On Wed, Mar 02, 2016 at 09:24:46AM +0800, Qu Wenruo wrote:
> 
> 
> Chris Mason wrote on 2016/03/01 20:11 -0500:
> >On Wed, Mar 02, 2016 at 08:48:06AM +0800, Qu Wenruo wrote:
> >>
> >>
> >>Chris Mason wrote on 2016/03/01 11:06 -0500:
> >>>On Tue, Mar 01, 2016 at 10:20:26AM +0100, David Sterba wrote:
> Hi Chris,
> 
> On Fri, Feb 26, 2016 at 01:22:00PM +, fdman...@kernel.org wrote:
> >The following changes since commit 
> >0fcb760afa6103419800674e22fb7f4de1f9670b:
> >
> >   Merge branch 'for-next' of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux into 
> > for-linus-4.6 (2016-02-24 10:21:44 -0800)
> >
> >are available in the git repository at:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git 
> > integration-4.6
> >
> >for you to fetch changes up to 97c86c11a5cb9839609a9df195e998c3312e68b0:
> >
> >   Btrfs: do not collect ordered extents when logging that inode exists 
> > (2016-02-26 04:28:15 +)
> 
> Filipe's branch is based on some integration snapshot that contains the
> 'delete device by id' patchset that was removed from the 4.6 queue.
> 
> Your branch 'next' merges it back again through Filipe's tree, besides
> that the merge commits of the topic branches in my for-next appear
> twice. While the duplicated commits are only an esthetic issue, the
> extra branch bothers me.
> 
> I don't see a nice way how to avoid rebases in this cases. My suggestion
> is that Filipe rebases the branch on my for-chris that could have been
> an integration at some point.
> 
> As we're merging our branches that way for the first time I'd like to
> find the workflow also for the next dev cycles so I'm open to other
> suggestions.
> >>>
> >>>Ugh, thanks Dave I missed this.  I'll rebase Filipe on top of your
> >>>branch.  The easiest way to avoid it in general is to only base trees on
> >>>top of things already in Linus' tree.  If there are specific
> >>>dependencies we can work it out on a case by case basis, but the merge
> >>>conflicts are almost always trivial.
> >>>
> >>>-chris
> >>
> >>Although off-topic, but do we need to rebase all sent pull to the new
> >>integration-4.6?
> >
> >Unless there are huge conflicts, it's actually much easier to base
> >against a recent v4.5-rcN.  That way if we do have to rebase the
> >integration branch, it doesn't mess up your pull request.
> >
> >If there are small conflicts, I can just deal with them when I pull.
> >For bigger conflicts, I'll either rebase on top of integration as
> >individual patches, or ask for help ;)
> 
> Thanks for the tip.
> Seems git can handle them well. (yeah, no more patch bombing )

Please keep patch bombing ;)  It's the best way to get things reviewed.
Besides, if people didn't like email, they would have found different
jobs long ago ;)

-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes for 4.6

2016-03-01 Thread Qu Wenruo 



Chris Mason wrote on 2016/03/01 20:11 -0500:

On Wed, Mar 02, 2016 at 08:48:06AM +0800, Qu Wenruo wrote:



Chris Mason wrote on 2016/03/01 11:06 -0500:

On Tue, Mar 01, 2016 at 10:20:26AM +0100, David Sterba wrote:

Hi Chris,

On Fri, Feb 26, 2016 at 01:22:00PM +, fdman...@kernel.org wrote:

The following changes since commit 0fcb760afa6103419800674e22fb7f4de1f9670b:

   Merge branch 'for-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux into for-linus-4.6 
(2016-02-24 10:21:44 -0800)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git 
integration-4.6

for you to fetch changes up to 97c86c11a5cb9839609a9df195e998c3312e68b0:

   Btrfs: do not collect ordered extents when logging that inode exists 
(2016-02-26 04:28:15 +)


Filipe's branch is based on some integration snapshot that contains the
'delete device by id' patchset that was removed from the 4.6 queue.

Your branch 'next' merges it back again through Filipe's tree, besides
that the merge commits of the topic branches in my for-next appear
twice. While the duplicated commits are only an esthetic issue, the
extra branch bothers me.

I don't see a nice way how to avoid rebases in this cases. My suggestion
is that Filipe rebases the branch on my for-chris that could have been
an integration at some point.

As we're merging our branches that way for the first time I'd like to
find the workflow also for the next dev cycles so I'm open to other
suggestions.


Ugh, thanks Dave I missed this.  I'll rebase Filipe on top of your
branch.  The easiest way to avoid it in general is to only base trees on
top of things already in Linus' tree.  If there are specific
dependencies we can work it out on a case by case basis, but the merge
conflicts are almost always trivial.

-chris


Although off-topic, but do we need to rebase all sent pull to the new
integration-4.6?


Unless there are huge conflicts, it's actually much easier to base
against a recent v4.5-rcN.  That way if we do have to rebase the
integration branch, it doesn't mess up your pull request.

If there are small conflicts, I can just deal with them when I pull.
For bigger conflicts, I'll either rebase on top of integration as
individual patches, or ask for help ;)


Thanks for the tip.
Seems git can handle them well. (yeah, no more patch bombing )




Yes, I mean the in-band de-dup patchset. (If it is going to be merged)


For de-dup, I need to sit down and spend some more time reviewing it.  I
know it's taking a long time, but I want to make sure we get the disk
format right up front.  Lets target v4.7.


OK, I'll ensure no more modification to the existing patchset for easier 
review.


Although we will continue adding minor features like compression with 
dedup or ioctl improvement, so I'm afraid we'll continue bombing mail 
list with 20+ patches. :)


Thanks,
Qu


-chris





--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes for 4.6

2016-03-01 Thread Chris Mason 
On Wed, Mar 02, 2016 at 08:48:06AM +0800, Qu Wenruo wrote:
> 
> 
> Chris Mason wrote on 2016/03/01 11:06 -0500:
> >On Tue, Mar 01, 2016 at 10:20:26AM +0100, David Sterba wrote:
> >>Hi Chris,
> >>
> >>On Fri, Feb 26, 2016 at 01:22:00PM +, fdman...@kernel.org wrote:
> >>>The following changes since commit 
> >>>0fcb760afa6103419800674e22fb7f4de1f9670b:
> >>>
> >>>   Merge branch 'for-next' of 
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux into 
> >>> for-linus-4.6 (2016-02-24 10:21:44 -0800)
> >>>
> >>>are available in the git repository at:
> >>>
> >>>   git://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git 
> >>> integration-4.6
> >>>
> >>>for you to fetch changes up to 97c86c11a5cb9839609a9df195e998c3312e68b0:
> >>>
> >>>   Btrfs: do not collect ordered extents when logging that inode exists 
> >>> (2016-02-26 04:28:15 +)
> >>
> >>Filipe's branch is based on some integration snapshot that contains the
> >>'delete device by id' patchset that was removed from the 4.6 queue.
> >>
> >>Your branch 'next' merges it back again through Filipe's tree, besides
> >>that the merge commits of the topic branches in my for-next appear
> >>twice. While the duplicated commits are only an esthetic issue, the
> >>extra branch bothers me.
> >>
> >>I don't see a nice way how to avoid rebases in this cases. My suggestion
> >>is that Filipe rebases the branch on my for-chris that could have been
> >>an integration at some point.
> >>
> >>As we're merging our branches that way for the first time I'd like to
> >>find the workflow also for the next dev cycles so I'm open to other
> >>suggestions.
> >
> >Ugh, thanks Dave I missed this.  I'll rebase Filipe on top of your
> >branch.  The easiest way to avoid it in general is to only base trees on
> >top of things already in Linus' tree.  If there are specific
> >dependencies we can work it out on a case by case basis, but the merge
> >conflicts are almost always trivial.
> >
> >-chris
> 
> Although off-topic, but do we need to rebase all sent pull to the new
> integration-4.6?

Unless there are huge conflicts, it's actually much easier to base
against a recent v4.5-rcN.  That way if we do have to rebase the
integration branch, it doesn't mess up your pull request.

If there are small conflicts, I can just deal with them when I pull.
For bigger conflicts, I'll either rebase on top of integration as
individual patches, or ask for help ;)

> Yes, I mean the in-band de-dup patchset. (If it is going to be merged)

For de-dup, I need to sit down and spend some more time reviewing it.  I
know it's taking a long time, but I want to make sure we get the disk
format right up front.  Lets target v4.7.

-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes for 4.6

2016-03-01 Thread Qu Wenruo 



Chris Mason wrote on 2016/03/01 11:06 -0500:

On Tue, Mar 01, 2016 at 10:20:26AM +0100, David Sterba wrote:

Hi Chris,

On Fri, Feb 26, 2016 at 01:22:00PM +, fdman...@kernel.org wrote:

The following changes since commit 0fcb760afa6103419800674e22fb7f4de1f9670b:

   Merge branch 'for-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux into for-linus-4.6 
(2016-02-24 10:21:44 -0800)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git 
integration-4.6

for you to fetch changes up to 97c86c11a5cb9839609a9df195e998c3312e68b0:

   Btrfs: do not collect ordered extents when logging that inode exists 
(2016-02-26 04:28:15 +)


Filipe's branch is based on some integration snapshot that contains the
'delete device by id' patchset that was removed from the 4.6 queue.

Your branch 'next' merges it back again through Filipe's tree, besides
that the merge commits of the topic branches in my for-next appear
twice. While the duplicated commits are only an esthetic issue, the
extra branch bothers me.

I don't see a nice way how to avoid rebases in this cases. My suggestion
is that Filipe rebases the branch on my for-chris that could have been
an integration at some point.

As we're merging our branches that way for the first time I'd like to
find the workflow also for the next dev cycles so I'm open to other
suggestions.


Ugh, thanks Dave I missed this.  I'll rebase Filipe on top of your
branch.  The easiest way to avoid it in general is to only base trees on
top of things already in Linus' tree.  If there are specific
dependencies we can work it out on a case by case basis, but the merge
conflicts are almost always trivial.

-chris


Although off-topic, but do we need to rebase all sent pull to the new 
integration-4.6?

Yes, I mean the in-band de-dup patchset. (If it is going to be merged)

Thanks,
Qu

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html





--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes for 4.6

2016-03-01 Thread Chris Mason 
On Tue, Mar 01, 2016 at 10:20:26AM +0100, David Sterba wrote:
> Hi Chris,
> 
> On Fri, Feb 26, 2016 at 01:22:00PM +, fdman...@kernel.org wrote:
> > The following changes since commit 0fcb760afa6103419800674e22fb7f4de1f9670b:
> > 
> >   Merge branch 'for-next' of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux into 
> > for-linus-4.6 (2016-02-24 10:21:44 -0800)
> > 
> > are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git 
> > integration-4.6
> > 
> > for you to fetch changes up to 97c86c11a5cb9839609a9df195e998c3312e68b0:
> > 
> >   Btrfs: do not collect ordered extents when logging that inode exists 
> > (2016-02-26 04:28:15 +)
> 
> Filipe's branch is based on some integration snapshot that contains the
> 'delete device by id' patchset that was removed from the 4.6 queue.
> 
> Your branch 'next' merges it back again through Filipe's tree, besides
> that the merge commits of the topic branches in my for-next appear
> twice. While the duplicated commits are only an esthetic issue, the
> extra branch bothers me.
> 
> I don't see a nice way how to avoid rebases in this cases. My suggestion
> is that Filipe rebases the branch on my for-chris that could have been
> an integration at some point.
> 
> As we're merging our branches that way for the first time I'd like to
> find the workflow also for the next dev cycles so I'm open to other
> suggestions.

Ugh, thanks Dave I missed this.  I'll rebase Filipe on top of your
branch.  The easiest way to avoid it in general is to only base trees on
top of things already in Linus' tree.  If there are specific
dependencies we can work it out on a case by case basis, but the merge
conflicts are almost always trivial.

-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Btrfs fixes for 4.6

2016-03-01 Thread David Sterba 
Hi Chris,

On Fri, Feb 26, 2016 at 01:22:00PM +, fdman...@kernel.org wrote:
> The following changes since commit 0fcb760afa6103419800674e22fb7f4de1f9670b:
> 
>   Merge branch 'for-next' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux into for-linus-4.6 
> (2016-02-24 10:21:44 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git 
> integration-4.6
> 
> for you to fetch changes up to 97c86c11a5cb9839609a9df195e998c3312e68b0:
> 
>   Btrfs: do not collect ordered extents when logging that inode exists 
> (2016-02-26 04:28:15 +)

Filipe's branch is based on some integration snapshot that contains the
'delete device by id' patchset that was removed from the 4.6 queue.

Your branch 'next' merges it back again through Filipe's tree, besides
that the merge commits of the topic branches in my for-next appear
twice. While the duplicated commits are only an esthetic issue, the
extra branch bothers me.

I don't see a nice way how to avoid rebases in this cases. My suggestion
is that Filipe rebases the branch on my for-chris that could have been
an integration at some point.

As we're merging our branches that way for the first time I'd like to
find the workflow also for the next dev cycles so I'm open to other
suggestions.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] Btrfs fixes for 4.6

2016-02-26 Thread fdmanana 
From: Filipe Manana 

Hi Chris,

Please consider the following changes for the 4.6 kernel merge window.
Nothing particularly outstanding, just the usual sort of bug fixes.
These have all been sent to the mailing list before (I just changed in
my repo the changelog for the deadlock fix patch to fix a typo pointed
by Liu Bo, other than that it's exactly the same as the version sent to
the mailing list). Some xfstests for these were already merged upstream
and one more sent earlier this week (for the listxattrs issue) that is
not yet merged.

Thanks.

The following changes since commit 0fcb760afa6103419800674e22fb7f4de1f9670b:

  Merge branch 'for-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux into for-linus-4.6 
(2016-02-24 10:21:44 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git 
integration-4.6

for you to fetch changes up to 97c86c11a5cb9839609a9df195e998c3312e68b0:

  Btrfs: do not collect ordered extents when logging that inode exists 
(2016-02-26 04:28:15 +)


Filipe Manana (7):
  Btrfs: fix unreplayable log after snapshot delete + parent dir fsync
  Btrfs: fix file loss on log replay after renaming a file and fsync
  Btrfs: fix extent_same allowing destination offset beyond i_size
  Btrfs: fix deadlock between direct IO reads and buffered writes
  Btrfs: fix listxattrs not listing all xattrs packed in the same item
  Btrfs: fix race when checking if we can skip fsync'ing an inode
  Btrfs: do not collect ordered extents when logging that inode exists

 fs/btrfs/file.c |  9 +
 fs/btrfs/inode.c| 25 +++--
 fs/btrfs/ioctl.c|  6 ++
 fs/btrfs/tree-log.c | 99 
---
 fs/btrfs/tree-log.h |  2 ++
 fs/btrfs/xattr.c| 65 
+
 6 files changed, 165 insertions(+), 41 deletions(-)

-- 
2.7.0.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html