Hi everyone, I''ve pulled in Hugo''s integration tree, minus the features that were not yet in the kernel. This also has a few small commits that I had queued up outside of the fsck work. Hugo, many thanks for keeping up the integration tree! Taking out the features not in the kernel meant I had to rebase it the commits, I''m sorry about that. The code from the integration tree is here: git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git My next step is to push out a branch with Josef''s recovery tool integrated in. I''m spending some time adding my metadata scanning code with his, and trying to clean up things for a real beta fsck release. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 27, 2011 at 11:27:07AM -0400, Chris Mason wrote:> I''ve pulled in Hugo''s integration tree, minus the features that were not > yet in the kernel. This also has a few small commits that I had queued > up outside of the fsck work. > > Hugo, many thanks for keeping up the integration tree! Taking out the > features not in the kernel meant I had to rebase it the commits, I''m > sorry about that.OK, I''m sure I can cope with that. I''ll just drop the patches from my stack that you''ve already brought in, and generate a new integration branch based on your master. I''ve got 4-5 other patches to add in as well, gleaned from the mailing list and, via David Sterba, from SuSE''s local patches. I''ve also got the basis of a set of regression tests for -progs, which I''ll send out patches for in the next couple of days. At the moment, it only tests building and snapshots, but should be relatively easily extensible to the other bits of ./btrfs (although I''m not sure how we can easily and repeatably test the recovery tools). One other thing that''s *really* needed is a new version tag, which I was going to do this weekend, but it looks like you''re back at the helm of -progs, so I''ll just whine in your general direction instead. I''ll try to keep up with the integration branch still, and feed public patches I pull off the mailing list through to you, if that''s going to continue to be useful. At the moment, though, I''m doing very little in the way of active review on these patches, so the fact that a patch is in integration-* doesn''t necessarily mean that it''s passed any kind of quality check from me.> The code from the integration tree is here: > > git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git > > My next step is to push out a branch with Josef''s recovery tool > integrated in. I''m spending some time adding my metadata scanning code > with his, and trying to clean up things for a real beta fsck release.Looking forward to it. :) Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk == PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Great oxymorons of the world, no. 4: Future Perfect ---
On Thu, Oct 27, 2011 at 04:58:54PM +0100, Hugo Mills wrote:> On Thu, Oct 27, 2011 at 11:27:07AM -0400, Chris Mason wrote: > > I''ve pulled in Hugo''s integration tree, minus the features that were not > > yet in the kernel. This also has a few small commits that I had queued > > up outside of the fsck work. > > > > Hugo, many thanks for keeping up the integration tree! Taking out the > > features not in the kernel meant I had to rebase it the commits, I''m > > sorry about that. > > OK, I''m sure I can cope with that. I''ll just drop the patches from > my stack that you''ve already brought in, and generate a new > integration branch based on your master. I''ve got 4-5 other patches to > add in as well, gleaned from the mailing list and, via David Sterba, > from SuSE''s local patches. > > I''ve also got the basis of a set of regression tests for -progs, > which I''ll send out patches for in the next couple of days. At the > moment, it only tests building and snapshots, but should be relatively > easily extensible to the other bits of ./btrfs (although I''m not sure > how we can easily and repeatably test the recovery tools).Please talk with Anand Jain on the test programs, he has been making scripts for xfs-tests.> > One other thing that''s *really* needed is a new version tag, which > I was going to do this weekend, but it looks like you''re back at the > helm of -progs, so I''ll just whine in your general direction instead.Definitely, fsck deserves a new version tag.> > I''ll try to keep up with the integration branch still, and feed > public patches I pull off the mailing list through to you, if that''s > going to continue to be useful. At the moment, though, I''m doing very > little in the way of active review on these patches, so the fact that > a patch is in integration-* doesn''t necessarily mean that it''s passed > any kind of quality check from me.That''s great, it still helps. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 27, 2011 at 05:32:58PM -0400, Chris Mason wrote:> On Thu, Oct 27, 2011 at 04:58:54PM +0100, Hugo Mills wrote: > > On Thu, Oct 27, 2011 at 11:27:07AM -0400, Chris Mason wrote: > > > I''ve pulled in Hugo''s integration tree, minus the features that were not > > > yet in the kernel. This also has a few small commits that I had queued > > > up outside of the fsck work. > > > > > > Hugo, many thanks for keeping up the integration tree! Taking out the > > > features not in the kernel meant I had to rebase it the commits, I''m > > > sorry about that. > > > > OK, I''m sure I can cope with that. I''ll just drop the patches from > > my stack that you''ve already brought in, and generate a new > > integration branch based on your master. I''ve got 4-5 other patches to > > add in as well, gleaned from the mailing list and, via David Sterba, > > from SuSE''s local patches. > > > > I''ve also got the basis of a set of regression tests for -progs, > > which I''ll send out patches for in the next couple of days. At the > > moment, it only tests building and snapshots, but should be relatively > > easily extensible to the other bits of ./btrfs (although I''m not sure > > how we can easily and repeatably test the recovery tools). > > Please talk with Anand Jain on the test programs, he has been making > scripts for xfs-tests.Will do, although I think we''re aiming at different things. I''m very definitely *not* attempting to test the filesystem itself with my test harness. I just want to exercise all the bits of the userspace tools that I can. (This was primarily triggered by the mess surrounding the parsing of "btrfs sub snap" parameters).> > One other thing that''s *really* needed is a new version tag, which > > I was going to do this weekend, but it looks like you''re back at the > > helm of -progs, so I''ll just whine in your general direction instead. > > Definitely, fsck deserves a new version tag.You mean we''ve got to wait *that* long? ;) Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk == PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- "I don''t like the look of it, I tell you." "Well, stop --- looking at it, then."
>>> I''ve also got the basis of a set of regression tests for -progs, >>> which I''ll send out patches for in the next couple of days. At the >>> moment, it only tests building and snapshots, but should be relatively >>> easily extensible to the other bits of ./btrfs (although I''m not sure >>> how we can easily and repeatably test the recovery tools). >> >> Please talk with Anand Jain on the test programs, he has been making >> scripts for xfs-tests. > > Will do, although I think we''re aiming at different things. I''m > very definitely *not* attempting to test the filesystem itself with my > test harness. I just want to exercise all the bits of the userspace > tools that I can. (This was primarily triggered by the mess > surrounding the parsing of "btrfs sub snap" parameters).Testing the (btrfs) CLI wasn''t aimed in the xfs-tests instead the FS itself. Appears that btrfs CLI syntax-change is upcoming what we might also need is a CLI to check the version of both btrfs and btrfs-progs to ensure tools surrounding them will report -incompatible instead of syntax error. thanks. -Anand -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> Hi everyone, > > I''ve pulled in Hugo''s integration tree, minus the features that were not > yet in the kernel. This also has a few small commits that I had queued > up outside of the fsck work. > > Hugo, many thanks for keeping up the integration tree! Taking out the > features not in the kernel meant I had to rebase it the commits, I''m > sorry about that. > > The code from the integration tree is here: > > git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.gitSounds great! Should we treat is as new home of a thing called "-unstable" before? git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git Or you are planning to restore that repo as well? Thanks! -- Sergei
On Fri, Oct 28, 2011 at 07:27:56PM +0300, Sergei Trofimovich wrote:> > Hi everyone, > > > > I''ve pulled in Hugo''s integration tree, minus the features that were not > > yet in the kernel. This also has a few small commits that I had queued > > up outside of the fsck work. > > > > Hugo, many thanks for keeping up the integration tree! Taking out the > > features not in the kernel meant I had to rebase it the commits, I''m > > sorry about that. > > > > The code from the integration tree is here: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git > > Sounds great! Should we treat is as new home of a thing called "-unstable" before? > > git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git > > Or you are planning to restore that repo as well?That''s a good point, I''ll see if I can make the -unstable a link. Still figuring out the new git interface. But yes, this is the new home of the progs. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/27/2011 11:27 AM, Chris Mason wrote:> Hi everyone, > > I''ve pulled in Hugo''s integration tree, minus the features that were not > yet in the kernel. This also has a few small commits that I had queued > up outside of the fsck work. > > Hugo, many thanks for keeping up the integration tree! Taking out the > features not in the kernel meant I had to rebase it the commits, I''m > sorry about that. > > The code from the integration tree is here: > > git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.gitI notice that there are no tags in the repo. Did you just forget to push them, or have they been lost? Also the repository description still needs filled out. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html