New btrfs-progs integration branch

New btrfs-progs integration branch

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 2688 bytes --]

   I've just pushed out a new integration branch to my git repo. This
is purely bugfix patches -- there are no new features in this issue of
the integration branch. I've got a stack of about a dozen more patches
with new features in them still to go. I'll be working on those
tomorrow. As always, there's minimal testing involved here, but it
does at least compile on my system(*).

   The branch is fetchable with git from:

http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ integration-20120605

   And viewable in human-readable form at:

http://git.darksatanic.net/cgi/gitweb.cgi?p=btrfs-progs-unstable.git

   Shortlog is below.

   Hugo.

(*) "I don't care about works-on-my-machine. We are not shipping your
machine!"

----

Akira Fujita (1):
      Btrfs-progs: Fix manual of btrfs command

Chris Samuel (1):
      Fix "set-dafault" typo in cmds-subvolume.c

Csaba Tóth (1):
      mkfs.btrfs on ARM

Goffredo Baroncelli (1):
      scrub_fs_info( ) file handle leaking

Hubert Kario (2):
      Fix segmentation fault when opening invalid file system
      man: fix btrfs man page formatting

Jan Kara (1):
      mkfs: Handle creation of filesystem larger than the first device

Jim Meyering (5):
      btrfs_scan_one_dir: avoid use-after-free on error path
      mkfs: use strdup in place of strlen,malloc,strcpy sequence
      restore: don't corrupt stack for a zero-length command-line argument
      avoid several strncpy-induced buffer overruns
      mkfs: avoid heap-buffer-read-underrun for zero-length "size" arg

Josef Bacik (3):
      Btrfs-progs: make btrfsck aware of free space inodes
      Btrfs-progs: make btrfs filesystem show <uuid> actually work
      btrfs-progs: enforce block count on all devices in mkfs

Miao Xie (3):
      Btrfs-progs: fix btrfsck's snapshot wrong "unresolved refs"
      Btrfs-progs, btrfs-corrupt-block: fix the wrong usage
      Btrfs-progs, btrfs-map-logical: Fix typo in usage

Phillip Susi (2):
      btrfs-progs: removed extraneous whitespace from mkfs man page
      btrfs-progs: document --rootdir mkfs switch

Sergei Trofimovich (2):
      Makefile: use $(CC) as a compilers instead of $(CC)/gcc
      Makefile: use $(MAKE) instead of hardcoded 'make'

Shawn Bohrer (1):
      btrfs-progs: Update resize documentation

Wang Sheng-Hui (1):
      btrfs-progs: cleanup: remove the redundant BTRFS_CSUM_TYPE_CRC32 macro def

-- 
=== 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.  5: Manifesto Promise ---     

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: New btrfs-progs integration branch

[Helmut Hullen]

Hallo, Hugo,

Du meintest am 05.06.12:

>    The branch is fetchable with git from:

> http://git.darksatanic.net/repo/btrfs-progs-unstable.git/
> integration-20120605

There seems to be a bug inside:

[...]

gcc -g -O0 -o btrfsck btrfsck.o ctree.o disk-io.o radix-tree.o extent- 
tree.o print-tree.o root-tree.o dir-item.o file-item.o inode-item.o  
inode-map.o crc32c.o rbtree.o extent-cache.o extent_io.o volumes.o  
utils.o btrfs-list.o btrfslabel.o repair.o  -luuid

gcc -g -O0 -o btrfs-convert ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o root-tree.o dir-item.o file-item.o inode-item.o inode-map.o crc32c.o rbtree.o extent-cache.o extent_io.o volumes.o utils.o btrfs-list.o btrfslabel.o repair.o convert.o -lext2fs -lcom_err  -luuid

gcc   convert.o   -o convert
convert.o: In function `btrfs_item_key':
/tmp/btrfs-progs-unstable/ctree.h:1404: undefined reference to `read_extent_buffer'
convert.o: In function `btrfs_dir_item_key':
/tmp/btrfs-progs-unstable/ctree.h:1437: undefined reference to `read_extent_buffer'
convert.o: In function `btrfs_del_item':

[...]

Viele Gruesse!
Helmut

Re: New btrfs-progs integration branch

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 2032 bytes --]

On Wed, Jun 06, 2012 at 01:48:00PM +0200, Helmut Hullen wrote:
> Hallo, Hugo,
> 
> Du meintest am 05.06.12:
> 
> >    The branch is fetchable with git from:
> 
> > http://git.darksatanic.net/repo/btrfs-progs-unstable.git/
> > integration-20120605
> 
> There seems to be a bug inside:
> 
> [...]
> 
> gcc -g -O0 -o btrfsck btrfsck.o ctree.o disk-io.o radix-tree.o extent- 
> tree.o print-tree.o root-tree.o dir-item.o file-item.o inode-item.o  
> inode-map.o crc32c.o rbtree.o extent-cache.o extent_io.o volumes.o  
> utils.o btrfs-list.o btrfslabel.o repair.o  -luuid
> 
> gcc -g -O0 -o btrfs-convert ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o root-tree.o dir-item.o file-item.o inode-item.o inode-map.o crc32c.o rbtree.o extent-cache.o extent_io.o volumes.o utils.o btrfs-list.o btrfslabel.o repair.o convert.o -lext2fs -lcom_err  -luuid
> 
> gcc   convert.o   -o convert
> convert.o: In function `btrfs_item_key':
> /tmp/btrfs-progs-unstable/ctree.h:1404: undefined reference to `read_extent_buffer'
> convert.o: In function `btrfs_dir_item_key':
> /tmp/btrfs-progs-unstable/ctree.h:1437: undefined reference to `read_extent_buffer'
> convert.o: In function `btrfs_del_item':

   Odd. I've just tried this on a clean clone of my repo, and it's
building fine. It's declared in extent_io.h, and defined in
extent_io.c.

   However, it does look like there's a problem with the make process:
my Makefile says:

btrfs-convert: $(objects) convert.o
        $(CC) $(CFLAGS) -o btrfs-convert $(objects) convert.o -lext2fs -lcom_err $(LDFLAGS) $(LIBS)

... which seems to be what the second line you quoted is doing.
However, the third line with the problem looks like something out of
date. Possibly a mis-merge?

   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 am but mad north-north-west:  when the wind is southerly, I ---  
                       know a hawk from a handsaw.                       

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: New btrfs-progs integration branch

[Helmut Hullen]

Hallo, Hugo,

Du meintest am 06.06.12:

> However, the third line with the problem looks like something out of
> date. Possibly a mis-merge?

Where should I search?

Viele Gruesse!
Helmut

Re: New btrfs-progs integration branch

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]

On Wed, Jun 06, 2012 at 05:03:00PM +0200, Helmut Hullen wrote:
> Hallo, Hugo,
> 
> Du meintest am 06.06.12:
> 
> > However, the third line with the problem looks like something out of
> > date. Possibly a mis-merge?
> 
> Where should I search?

   Well, the first thing would be to try a completely new clone of the
repo, then git co integration-20120605, and run make again. If that's
OK, then take a look with gitk in the broken repo and see what kind of
history you've got in there -- it should be a single unbroken sequence
from "master" (1957076ab4fefa47b6efed3da541bc974c83eed7) to
"integration-20120605" (d4c539067d1cb2476c7fb6003625de26e84059af).

   Also have a look in the Makefile of the broken repo -- all of the
commands (listed near the top, assigned to the "progs" variable)
should start with "btrfs", and there should be no rule for "convert"
in there. Again, if that's not the case, you've managed to mis-merge
or check out the wrong branch.

   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
   --- We are all lying in the gutter,  but some of us are looking ---   
                              at the stars.                              

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: New btrfs-progs integration branch

[Helmut Hullen]

Hallo, Hugo,

Du meintest am 06.06.12:

>>> However, the third line with the problem looks like something out
>>> of date. Possibly a mis-merge?
>>
>> Where should I search?

>    Well, the first thing would be to try a completely new clone of
> the repo, then git co integration-20120605, and run make again.

I had a brand new git clone.

Produced with

[...]
git clone http://git.darksatanic.net/repo/btrfs-progs-unstable.git
cd btrfs-progs-unstable
git checkout integration-20120605

(and "btrfs-progs-unstable" had been empty before "checkout")

> If
> that's OK, then take a look with gitk in the broken repo and see what
> kind of history you've got in there -- it should be a single unbroken
> sequence from "master" (1957076ab4fefa47b6efed3da541bc974c83eed7) to
> "integration-20120605" (d4c539067d1cb2476c7fb6003625de26e84059af).

I don't know much about working with git ... but I suppose I'm not  
working with such things as a (broken) repo.

It's the same way I had successfully compiled your version from 20111012  
and from 20111030.

Is there any change compiling the new version?

Viele Gruesse!
Helmut

Re: New btrfs-progs integration branch

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 2041 bytes --]

On Wed, Jun 06, 2012 at 05:52:00PM +0200, Helmut Hullen wrote:
> Hallo, Hugo,
> 
> Du meintest am 06.06.12:
> 
> >>> However, the third line with the problem looks like something out
> >>> of date. Possibly a mis-merge?
> >>
> >> Where should I search?
> 
> >    Well, the first thing would be to try a completely new clone of
> > the repo, then git co integration-20120605, and run make again.
> 
> I had a brand new git clone.
> 
> Produced with
> 
> [...]
> git clone http://git.darksatanic.net/repo/btrfs-progs-unstable.git
> cd btrfs-progs-unstable
> git checkout integration-20120605
> 
> (and "btrfs-progs-unstable" had been empty before "checkout")
> 
> > If
> > that's OK, then take a look with gitk in the broken repo and see what
> > kind of history you've got in there -- it should be a single unbroken
> > sequence from "master" (1957076ab4fefa47b6efed3da541bc974c83eed7) to
> > "integration-20120605" (d4c539067d1cb2476c7fb6003625de26e84059af).
> 
> I don't know much about working with git ... but I suppose I'm not  
> working with such things as a (broken) repo.
> 
> It's the same way I had successfully compiled your version from 20111012  
> and from 20111030.
> 
> Is there any change compiling the new version?

   No, just type make from the directory.

   Can you compare your Makefile with the one at [1] -- in particular
the progs variable at line 21-23, the "all" target on line 37, and the
"btrfs-convert" target on line 97. There definitely should not be a
plain "convert" target in there, but that seems to be what your system
was failing on.

   Hugo.

[1] http://git.darksatanic.net/cgi/gitweb.cgi?p=btrfs-progs-unstable.git;a=blob;f=Makefile;h=96944449366d506918db711245aa771d103698a7;hb=integration-20120605

-- 
=== 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
   --- We are all lying in the gutter,  but some of us are looking ---   
                              at the stars.                              

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: New btrfs-progs integration branch

[Helmut Hullen]

Hallo, Hugo,

Du meintest am 06.06.12:

>> git checkout integration-20120605

[...]
>    Can you compare your Makefile with the one at [1] -- in particular
> the progs variable at line 21-23, the "all" target on line 37, and
> the "btrfs-convert" target on line 97. There definitely should not be
> a plain "convert" target in there, but that seems to be what your
> system was failing on.

Makefile with 3888 Bytes.

"md5sum Makefile" shows

(my file)
deef961e3ecd560ad8710cf0b58f5570  Makefile

(the file from your link)
deef961e3ecd560ad8710cf0b58f5570  Makefile

The problem is somewhere on another place ...

Viele Gruesse!
Helmut

Re: New btrfs-progs integration branch

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]

On Wed, Jun 06, 2012 at 06:18:00PM +0200, Helmut Hullen wrote:
> Hallo, Hugo,
> 
> Du meintest am 06.06.12:
> 
> >> git checkout integration-20120605
> 
> [...]
> >    Can you compare your Makefile with the one at [1] -- in particular
> > the progs variable at line 21-23, the "all" target on line 37, and
> > the "btrfs-convert" target on line 97. There definitely should not be
> > a plain "convert" target in there, but that seems to be what your
> > system was failing on.
> 
> Makefile with 3888 Bytes.
> 
> "md5sum Makefile" shows
> 
> (my file)
> deef961e3ecd560ad8710cf0b58f5570  Makefile
> 
> (the file from your link)
> deef961e3ecd560ad8710cf0b58f5570  Makefile
> 
> The problem is somewhere on another place ...

   OK, can you send through the complete output of:

$ make clean
$ gcc --version
$ make --version
$ make
$ for f in .*.d; do echo == $d; cat $d; done

   My guess is that the dependency generation is going wrong somewhere.

   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
       --- There's many a slip 'twixt wicket-keeper and gully. ---       

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: New btrfs-progs integration branch

[Helmut Hullen]

Hallo, Hugo,

Du meintest am 06.06.12:

>>>    The branch is fetchable with git from:
>>
>>> http://git.darksatanic.net/repo/btrfs-progs-unstable.git/
>>> integration-20120605

>> gcc   convert.o   -o convert
>> convert.o: In function `btrfs_item_key':
>> /tmp/btrfs-progs-unstable/ctree.h:1404: undefined reference to
>> `read_extent_buffer' convert.o:

[...]
Solved - thanks for your help!

You have changed the Makefile;

        make convert

does not more work, it has changed to

        make btrfs-convert


-------------------------------

You can find the slackware binary at

  <http://helmut.hullen.de/filebox/Linux/slackware/ap/btrfs-progs-20120606-i486-1hln.txz>

Viele Gruesse!
Helmut

Re: New btrfs-progs integration branch

[Jérôme Poulin]

On Tue, Jun 5, 2012 at 3:09 PM, Hugo Mills <hugo@carfax.org.uk> wrote:
>
>   I've just pushed out a new integration branch to my git repo. This
> is purely bugfix patches -- there are no new features in this issue of
> the integration branch. I've got a stack of about a dozen more patches
> with new features in them still to go.


I was wondering if in the new patches you had the ReiserFS converter in queue?
http://www.spinics.net/lists/linux-btrfs/msg04985.html

It seems out for a while, I did try it out without any issue on my
main partition 2 years ago. This is not my patch but would you need
more testing before getting it integrated?

-- Repost, forgot to disable HTML.

Re: New btrfs-progs integration branch

[Alex Lyakas]

Hi Hugo,
forgive me, but I am somewhat confused.
What is the "main" repo of btrfs-progs, if there is such thing?
I see patches coming in, but no updates to
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git,
which I thought was the one.

Can you pls clarify where should I pull updates from for btrfs-progs?

Thanks,
Alex.



On Tue, Jun 5, 2012 at 10:09 PM, Hugo Mills <hugo@carfax.org.uk> wrote:
>   I've just pushed out a new integration branch to my git repo. This
> is purely bugfix patches -- there are no new features in this issue of
> the integration branch. I've got a stack of about a dozen more patches
> with new features in them still to go. I'll be working on those
> tomorrow. As always, there's minimal testing involved here, but it
> does at least compile on my system(*).
>
>   The branch is fetchable with git from:
>
> http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ integration-20120605
>
>   And viewable in human-readable form at:
>
> http://git.darksatanic.net/cgi/gitweb.cgi?p=btrfs-progs-unstable.git
>
>   Shortlog is below.
>
>   Hugo.
>
> (*) "I don't care about works-on-my-machine. We are not shipping your
> machine!"
>
> ----
>
> Akira Fujita (1):
>      Btrfs-progs: Fix manual of btrfs command
>
> Chris Samuel (1):
>      Fix "set-dafault" typo in cmds-subvolume.c
>
> Csaba Tóth (1):
>      mkfs.btrfs on ARM
>
> Goffredo Baroncelli (1):
>      scrub_fs_info( ) file handle leaking
>
> Hubert Kario (2):
>      Fix segmentation fault when opening invalid file system
>      man: fix btrfs man page formatting
>
> Jan Kara (1):
>      mkfs: Handle creation of filesystem larger than the first device
>
> Jim Meyering (5):
>      btrfs_scan_one_dir: avoid use-after-free on error path
>      mkfs: use strdup in place of strlen,malloc,strcpy sequence
>      restore: don't corrupt stack for a zero-length command-line argument
>      avoid several strncpy-induced buffer overruns
>      mkfs: avoid heap-buffer-read-underrun for zero-length "size" arg
>
> Josef Bacik (3):
>      Btrfs-progs: make btrfsck aware of free space inodes
>      Btrfs-progs: make btrfs filesystem show <uuid> actually work
>      btrfs-progs: enforce block count on all devices in mkfs
>
> Miao Xie (3):
>      Btrfs-progs: fix btrfsck's snapshot wrong "unresolved refs"
>      Btrfs-progs, btrfs-corrupt-block: fix the wrong usage
>      Btrfs-progs, btrfs-map-logical: Fix typo in usage
>
> Phillip Susi (2):
>      btrfs-progs: removed extraneous whitespace from mkfs man page
>      btrfs-progs: document --rootdir mkfs switch
>
> Sergei Trofimovich (2):
>      Makefile: use $(CC) as a compilers instead of $(CC)/gcc
>      Makefile: use $(MAKE) instead of hardcoded 'make'
>
> Shawn Bohrer (1):
>      btrfs-progs: Update resize documentation
>
> Wang Sheng-Hui (1):
>      btrfs-progs: cleanup: remove the redundant BTRFS_CSUM_TYPE_CRC32 macro def
>
> --
> === 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.  5: Manifesto Promise ---

Re: New btrfs-progs integration branch

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 4166 bytes --]

On Tue, Jun 26, 2012 at 11:58:41AM +0300, Alex Lyakas wrote:
> Hi Hugo,
> forgive me, but I am somewhat confused.
> What is the "main" repo of btrfs-progs, if there is such thing?
> I see patches coming in, but no updates to
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git,
> which I thought was the one.
> 
> Can you pls clarify where should I pull updates from for btrfs-progs?

   The official source for btrfs-progs is Chris's one, at the URL
above. The integration repo is kind of a staging area where I pull in
as many patches as I can and get them a bit more visibility. We don't
really have a well-defined workflow here.

   It depends on what you intend doing: if you want to make packages
for your distribution, use Chris's repo. If you want something
reasonably stable and tested, use Chris's repo. If there's some
experimental kernel feature you want to test out, use integration. If
you want to be helpful and test out new patches and report problems
with them, use integration.

   Hugo.

> Thanks,
> Alex.
> 
> 
> 
> On Tue, Jun 5, 2012 at 10:09 PM, Hugo Mills <hugo@carfax.org.uk> wrote:
> >   I've just pushed out a new integration branch to my git repo. This
> > is purely bugfix patches -- there are no new features in this issue of
> > the integration branch. I've got a stack of about a dozen more patches
> > with new features in them still to go. I'll be working on those
> > tomorrow. As always, there's minimal testing involved here, but it
> > does at least compile on my system(*).
> >
> >   The branch is fetchable with git from:
> >
> > http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ integration-20120605
> >
> >   And viewable in human-readable form at:
> >
> > http://git.darksatanic.net/cgi/gitweb.cgi?p=btrfs-progs-unstable.git
> >
> >   Shortlog is below.
> >
> >   Hugo.
> >
> > (*) "I don't care about works-on-my-machine. We are not shipping your
> > machine!"
> >
> > ----
> >
> > Akira Fujita (1):
> >      Btrfs-progs: Fix manual of btrfs command
> >
> > Chris Samuel (1):
> >      Fix "set-dafault" typo in cmds-subvolume.c
> >
> > Csaba Tóth (1):
> >      mkfs.btrfs on ARM
> >
> > Goffredo Baroncelli (1):
> >      scrub_fs_info( ) file handle leaking
> >
> > Hubert Kario (2):
> >      Fix segmentation fault when opening invalid file system
> >      man: fix btrfs man page formatting
> >
> > Jan Kara (1):
> >      mkfs: Handle creation of filesystem larger than the first device
> >
> > Jim Meyering (5):
> >      btrfs_scan_one_dir: avoid use-after-free on error path
> >      mkfs: use strdup in place of strlen,malloc,strcpy sequence
> >      restore: don't corrupt stack for a zero-length command-line argument
> >      avoid several strncpy-induced buffer overruns
> >      mkfs: avoid heap-buffer-read-underrun for zero-length "size" arg
> >
> > Josef Bacik (3):
> >      Btrfs-progs: make btrfsck aware of free space inodes
> >      Btrfs-progs: make btrfs filesystem show <uuid> actually work
> >      btrfs-progs: enforce block count on all devices in mkfs
> >
> > Miao Xie (3):
> >      Btrfs-progs: fix btrfsck's snapshot wrong "unresolved refs"
> >      Btrfs-progs, btrfs-corrupt-block: fix the wrong usage
> >      Btrfs-progs, btrfs-map-logical: Fix typo in usage
> >
> > Phillip Susi (2):
> >      btrfs-progs: removed extraneous whitespace from mkfs man page
> >      btrfs-progs: document --rootdir mkfs switch
> >
> > Sergei Trofimovich (2):
> >      Makefile: use $(CC) as a compilers instead of $(CC)/gcc
> >      Makefile: use $(MAKE) instead of hardcoded 'make'
> >
> > Shawn Bohrer (1):
> >      btrfs-progs: Update resize documentation
> >
> > Wang Sheng-Hui (1):
> >      btrfs-progs: cleanup: remove the redundant BTRFS_CSUM_TYPE_CRC32 macro def
> >

-- 
=== 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
          --- ...  one ping(1) to rule them all, and in the ---          
                         darkness bind(2) them.                          

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: New btrfs-progs integration branch

[Alex Lyakas]

Thanks, Hugo.
At this point I mostly want to learn and stay up-to-date with new
patches coming in.

Alex.



On Tue, Jun 26, 2012 at 12:58 PM, Hugo Mills <hugo@carfax.org.uk> wrote:
> On Tue, Jun 26, 2012 at 11:58:41AM +0300, Alex Lyakas wrote:
>> Hi Hugo,
>> forgive me, but I am somewhat confused.
>> What is the "main" repo of btrfs-progs, if there is such thing?
>> I see patches coming in, but no updates to
>> git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git,
>> which I thought was the one.
>>
>> Can you pls clarify where should I pull updates from for btrfs-progs?
>
>   The official source for btrfs-progs is Chris's one, at the URL
> above. The integration repo is kind of a staging area where I pull in
> as many patches as I can and get them a bit more visibility. We don't
> really have a well-defined workflow here.
>
>   It depends on what you intend doing: if you want to make packages
> for your distribution, use Chris's repo. If you want something
> reasonably stable and tested, use Chris's repo. If there's some
> experimental kernel feature you want to test out, use integration. If
> you want to be helpful and test out new patches and report problems
> with them, use integration.
>
>   Hugo.
>
>> Thanks,
>> Alex.
>>
>>
>>
>> On Tue, Jun 5, 2012 at 10:09 PM, Hugo Mills <hugo@carfax.org.uk> wrote:
>> >   I've just pushed out a new integration branch to my git repo. This
>> > is purely bugfix patches -- there are no new features in this issue of
>> > the integration branch. I've got a stack of about a dozen more patches
>> > with new features in them still to go. I'll be working on those
>> > tomorrow. As always, there's minimal testing involved here, but it
>> > does at least compile on my system(*).
>> >
>> >   The branch is fetchable with git from:
>> >
>> > http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ integration-20120605
>> >
>> >   And viewable in human-readable form at:
>> >
>> > http://git.darksatanic.net/cgi/gitweb.cgi?p=btrfs-progs-unstable.git
>> >
>> >   Shortlog is below.
>> >
>> >   Hugo.
>> >
>> > (*) "I don't care about works-on-my-machine. We are not shipping your
>> > machine!"
>> >
>> > ----
>> >
>> > Akira Fujita (1):
>> >      Btrfs-progs: Fix manual of btrfs command
>> >
>> > Chris Samuel (1):
>> >      Fix "set-dafault" typo in cmds-subvolume.c
>> >
>> > Csaba Tóth (1):
>> >      mkfs.btrfs on ARM
>> >
>> > Goffredo Baroncelli (1):
>> >      scrub_fs_info( ) file handle leaking
>> >
>> > Hubert Kario (2):
>> >      Fix segmentation fault when opening invalid file system
>> >      man: fix btrfs man page formatting
>> >
>> > Jan Kara (1):
>> >      mkfs: Handle creation of filesystem larger than the first device
>> >
>> > Jim Meyering (5):
>> >      btrfs_scan_one_dir: avoid use-after-free on error path
>> >      mkfs: use strdup in place of strlen,malloc,strcpy sequence
>> >      restore: don't corrupt stack for a zero-length command-line argument
>> >      avoid several strncpy-induced buffer overruns
>> >      mkfs: avoid heap-buffer-read-underrun for zero-length "size" arg
>> >
>> > Josef Bacik (3):
>> >      Btrfs-progs: make btrfsck aware of free space inodes
>> >      Btrfs-progs: make btrfs filesystem show <uuid> actually work
>> >      btrfs-progs: enforce block count on all devices in mkfs
>> >
>> > Miao Xie (3):
>> >      Btrfs-progs: fix btrfsck's snapshot wrong "unresolved refs"
>> >      Btrfs-progs, btrfs-corrupt-block: fix the wrong usage
>> >      Btrfs-progs, btrfs-map-logical: Fix typo in usage
>> >
>> > Phillip Susi (2):
>> >      btrfs-progs: removed extraneous whitespace from mkfs man page
>> >      btrfs-progs: document --rootdir mkfs switch
>> >
>> > Sergei Trofimovich (2):
>> >      Makefile: use $(CC) as a compilers instead of $(CC)/gcc
>> >      Makefile: use $(MAKE) instead of hardcoded 'make'
>> >
>> > Shawn Bohrer (1):
>> >      btrfs-progs: Update resize documentation
>> >
>> > Wang Sheng-Hui (1):
>> >      btrfs-progs: cleanup: remove the redundant BTRFS_CSUM_TYPE_CRC32 macro def
>> >
>
> --
> === 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
>          --- ...  one ping(1) to rule them all, and in the ---
>                         darkness bind(2) them.