[GIT PULL] btrfs-progs: more bugfixes for 0.20-rc1

[GIT PULL] btrfs-progs: more bugfixes for 0.20-rc1

[David Sterba]

Hi Chris,

please pull a few more fixes to the 0.20-rc series. I have reviewed and
verified them where possible. There are the long awaited ARM fixes, help
updates and unsorted code fixes.

  git://repo.or.cz/btrfs-progs-unstable/devel.git for-chris

Based on top of master commit
91d9eec1ff044394f2b98ee7fcb76713dd33b994

Thanks.
david

---
 btrfs-list.c      |   69 +++++++++++++++++++++++++-----------------------------
 btrfsck.c         |    3 +-
 cmds-filesystem.c |   26 --------------------
 cmds-inspect.c    |    5 ++-
 cmds-receive.c    |    4 ++-
 cmds-scrub.c      |    4 ++-
 cmds-send.c       |    9 ++++++-
 convert.c         |    5 +++
 ctree.h           |    8 ++++--
 debug-tree.c      |   10 +++++++
 disk-io.c         |   13 ++++++++--
 kerncompat.h      |   12 +++++++++
 man/btrfs.8.in    |    4 ---
 mkfs.c            |   35 ++-------------------------
 restore.c         |    7 +++--
 utils.c           |   48 +++++++++++++++++++++++++++++++++++++
 utils.h           |    2 +
 version.sh        |    2 -
 volumes.c         |    8 +++---
 19 files changed, 159 insertions(+), 115 deletions(-)
---
Alex Lyakas (1):
      btrfs-progs: Receive: preserve ownership for symlinks, by using 'lchown'

Arne Jansen (1):
      Btrfs-progs: fix unaligned accesses

David Sterba (2):
      btrfs-progs: do not send stream into a terminal
      btrfs-progs: ignore -a option in mkfs

Goffredo Baroncelli (3):
      Move parse_size() to utils.[hc]
      parse_size(): replace atoll() with strtoull()
      parse_size(): add new suffixes

Kenji Okimoto (3):
      btrfs-progs: plug a memory leak reported by cppcheck
      btrfs-progs: check malloc() result
      btrfs-progs: plug memory leaks in btrfs_scan_one_dir() reported by cppcheck.

Lluis Batlle i Rossell (1):
      btrfs-progs: Fix getopt on arm platforms

Sergei Trofimovich (1):
      version.sh: fix version when built from tarball

Simon Xu (2):
      btrfs-progs: remove "device show" from btrfs man page
      btrfs-progs: remove '-h' from btrfs man page

Wade Cline (1):
      Btrfs-progs: Fix compiler warnings on PPC64

Wang Sheng-Hui (3):
      btrfs-progs: add -V description in print_usage
      btrfs-progs: update usage description for debug-tree.c
      btrfs-progs: print the right mount checking info in restore.c

Zach Brown (1):
      btrfs-progs: fix 32bit int/pointer cast warnings

Re: [GIT PULL] btrfs-progs: more bugfixes for 0.20-rc1

[Chris Mason]

On Thu, Jan 17, 2013 at 10:47:21AM -0700, David Sterba wrote:
> Hi Chris,
> 
> please pull a few more fixes to the 0.20-rc series. I have reviewed and
> verified them where possible. There are the long awaited ARM fixes, help
> updates and unsorted code fixes.
> 
>   git://repo.or.cz/btrfs-progs-unstable/devel.git for-chris
> 
> Based on top of master commit
> 91d9eec1ff044394f2b98ee7fcb76713dd33b994

Thanks Dave, pulling these in.

-chris

Re: [GIT PULL] btrfs-progs: more bugfixes for 0.20-rc1

[Gene Czarcinski]

On 01/17/2013 12:47 PM, David Sterba wrote:
> Hi Chris,
>
> please pull a few more fixes to the 0.20-rc series. I have reviewed and
> verified them where possible. There are the long awaited ARM fixes, help
> updates and unsorted code fixes.
>
>    git://repo.or.cz/btrfs-progs-unstable/devel.git for-chris
>
> Based on top of master commit
> 91d9eec1ff044394f2b98ee7fcb76713dd33b994
>
> Thanks.
> david
>
> ---
>   btrfs-list.c      |   69 +++++++++++++++++++++++++-----------------------------
>   btrfsck.c         |    3 +-
>   cmds-filesystem.c |   26 --------------------
>   cmds-inspect.c    |    5 ++-
>   cmds-receive.c    |    4 ++-
>   cmds-scrub.c      |    4 ++-
>   cmds-send.c       |    9 ++++++-
>   convert.c         |    5 +++
>   ctree.h           |    8 ++++--
>   debug-tree.c      |   10 +++++++
>   disk-io.c         |   13 ++++++++--
>   kerncompat.h      |   12 +++++++++
>   man/btrfs.8.in    |    4 ---
>   mkfs.c            |   35 ++-------------------------
>   restore.c         |    7 +++--
>   utils.c           |   48 +++++++++++++++++++++++++++++++++++++
>   utils.h           |    2 +
>   version.sh        |    2 -
>   volumes.c         |    8 +++---
>   19 files changed, 159 insertions(+), 115 deletions(-)
> ---
> Alex Lyakas (1):
>        btrfs-progs: Receive: preserve ownership for symlinks, by using 'lchown'
>
> Arne Jansen (1):
>        Btrfs-progs: fix unaligned accesses
>
> David Sterba (2):
>        btrfs-progs: do not send stream into a terminal
>        btrfs-progs: ignore -a option in mkfs
>
> Goffredo Baroncelli (3):
>        Move parse_size() to utils.[hc]
>        parse_size(): replace atoll() with strtoull()
>        parse_size(): add new suffixes
>
> Kenji Okimoto (3):
>        btrfs-progs: plug a memory leak reported by cppcheck
>        btrfs-progs: check malloc() result
>        btrfs-progs: plug memory leaks in btrfs_scan_one_dir() reported by cppcheck.
>
> Lluis Batlle i Rossell (1):
>        btrfs-progs: Fix getopt on arm platforms
>
> Sergei Trofimovich (1):
>        version.sh: fix version when built from tarball
While you are about it, how about adding in this fix from Dieter Ries to 
fix version a little more:
http://article.gmane.org/gmane.comp.file-systems.btrfs/20069
>
> Simon Xu (2):
>        btrfs-progs: remove "device show" from btrfs man page
>        btrfs-progs: remove '-h' from btrfs man page
>
> Wade Cline (1):
>        Btrfs-progs: Fix compiler warnings on PPC64
>
> Wang Sheng-Hui (3):
>        btrfs-progs: add -V description in print_usage
>        btrfs-progs: update usage description for debug-tree.c
>        btrfs-progs: print the right mount checking info in restore.c
>
> Zach Brown (1):
>        btrfs-progs: fix 32bit int/pointer cast warnings
>
>

Re: [GIT PULL] btrfs-progs: more bugfixes for 0.20-rc1

[David Sterba]

On Fri, Jan 18, 2013 at 09:16:00AM -0500, Gene Czarcinski wrote:
> >Sergei Trofimovich (1):
> >       version.sh: fix version when built from tarball
> While you are about it, how about adding in this fix from Dieter Ries to fix
> version a little more:
> http://article.gmane.org/gmane.comp.file-systems.btrfs/20069

I did not notice it before, but Dieter's patch does not work when progs
are built from .git repository

-echo "#define BTRFS_BUILD_VERSION \"Btrfs $v\"" >> .build-version.h
+echo "#define BTRFS_BUILD_VERSION \"$v\"" >> .build-version.h

$v is set with the git tag, so the "Btrfs" string does not appear in the
output (eg. mkfs.btrfs).

Technically, $v should always contain some sort of a tag, Sergei's patch
hardcodes it to the latest one for the non-git case. This is IMHO the
right approach.

david

Re: [GIT PULL] btrfs-progs: more bugfixes for 0.20-rc1

[Gene Czarcinski]

On 01/17/2013 12:47 PM, David Sterba wrote:
> Hi Chris,
>
> please pull a few more fixes to the 0.20-rc series. I have reviewed and
> verified them where possible. There are the long awaited ARM fixes, help
> updates and unsorted code fixes.
>
>    git://repo.or.cz/btrfs-progs-unstable/devel.git for-chris
>
> Based on top of master commit
> 91d9eec1ff044394f2b98ee7fcb76713dd33b994
>
> Thanks.
> david
>
> ---
>   btrfs-list.c      |   69 +++++++++++++++++++++++++-----------------------------
>   btrfsck.c         |    3 +-
>   cmds-filesystem.c |   26 --------------------
>   cmds-inspect.c    |    5 ++-
>   cmds-receive.c    |    4 ++-
>   cmds-scrub.c      |    4 ++-
>   cmds-send.c       |    9 ++++++-
>   convert.c         |    5 +++
>   ctree.h           |    8 ++++--
>   debug-tree.c      |   10 +++++++
>   disk-io.c         |   13 ++++++++--
>   kerncompat.h      |   12 +++++++++
>   man/btrfs.8.in    |    4 ---
>   mkfs.c            |   35 ++-------------------------
>   restore.c         |    7 +++--
>   utils.c           |   48 +++++++++++++++++++++++++++++++++++++
>   utils.h           |    2 +
>   version.sh        |    2 -
>   volumes.c         |    8 +++---
>   19 files changed, 159 insertions(+), 115 deletions(-)
> ---
> Alex Lyakas (1):
>        btrfs-progs: Receive: preserve ownership for symlinks, by using 'lchown'
>
> Arne Jansen (1):
>        Btrfs-progs: fix unaligned accesses
>
> David Sterba (2):
>        btrfs-progs: do not send stream into a terminal
>        btrfs-progs: ignore -a option in mkfs
>
> Goffredo Baroncelli (3):
>        Move parse_size() to utils.[hc]
>        parse_size(): replace atoll() with strtoull()
>        parse_size(): add new suffixes
>
> Kenji Okimoto (3):
>        btrfs-progs: plug a memory leak reported by cppcheck
>        btrfs-progs: check malloc() result
>        btrfs-progs: plug memory leaks in btrfs_scan_one_dir() reported by cppcheck.
>
> Lluis Batlle i Rossell (1):
>        btrfs-progs: Fix getopt on arm platforms
>
> Sergei Trofimovich (1):
>        version.sh: fix version when built from tarball
>
> Simon Xu (2):
>        btrfs-progs: remove "device show" from btrfs man page
>        btrfs-progs: remove '-h' from btrfs man page
>
> Wade Cline (1):
>        Btrfs-progs: Fix compiler warnings on PPC64
>
> Wang Sheng-Hui (3):
>        btrfs-progs: add -V description in print_usage
>        btrfs-progs: update usage description for debug-tree.c
>        btrfs-progs: print the right mount checking info in restore.c
>
> Zach Brown (1):
>        btrfs-progs: fix 32bit int/pointer cast warnings
>

David, first of all let me thank you for pulling these together.  I do 
not believe I am alone in wondering what was happening to the 
btrfs-progs patches on the mailing list.

I would like to recommend some additional patches for inclusion since 
they are currently part of the Fedora 18 btrfs-tools package.

Josef Bacik:  detect if the disk we are formatting is a ssd V2
http://article.gmane.org/gmane.comp.file-systems.btrfs/18749

This one may be a little more of a problem since the suggested man 
update is missing and there is a second part for the kernel (status 
unknown).
Josef Bacik:  add btrfs device ready command
http://article.gmane.org/gmane.comp.file-systems.btrfs/18129
Since Fedora uses a "stock" a kernel as possible, I suspect the 
corresponding patch is applied.

There are two or three other patches that appear to make sense but I 
have no idea if they have been submitted.

Gene

Re: [GIT PULL] btrfs-progs: more bugfixes for 0.20-rc1

[Gene Czarcinski]

On 01/18/2013 09:44 AM, David Sterba wrote:
> On Fri, Jan 18, 2013 at 09:16:00AM -0500, Gene Czarcinski wrote:
>>> Sergei Trofimovich (1):
>>>        version.sh: fix version when built from tarball
>> While you are about it, how about adding in this fix from Dieter Ries to fix
>> version a little more:
>> http://article.gmane.org/gmane.comp.file-systems.btrfs/20069
> I did not notice it before, but Dieter's patch does not work when progs
> are built from .git repository
>
> -echo "#define BTRFS_BUILD_VERSION \"Btrfs $v\"" >> .build-version.h
> +echo "#define BTRFS_BUILD_VERSION \"$v\"" >> .build-version.h
>
> $v is set with the git tag, so the "Btrfs" string does not appear in the
> output (eg. mkfs.btrfs).
>
> Technically, $v should always contain some sort of a tag, Sergei's patch
> hardcodes it to the latest one for the non-git case. This is IMHO the
> right approach.
>
OK, I see what you mean.  However, the current situation when btrfs is 
built from a tarball results in:

 >btrfs  --version
Btrfs Btrfs v0.19

and

 >mkfs.btrfs  -V
mkfs.btrfs, part of Btrfs Btrfs v0.19

There must be a way to reliably just have one "Btrfs" and I will look 
into it.

Gene

Re: [GIT PULL] btrfs-progs: more bugfixes for 0.20-rc1

[Hugo Mills]

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

On Fri, Jan 18, 2013 at 10:49:20AM -0500, Gene Czarcinski wrote:
> On 01/18/2013 09:44 AM, David Sterba wrote:
> >On Fri, Jan 18, 2013 at 09:16:00AM -0500, Gene Czarcinski wrote:
> >>>Sergei Trofimovich (1):
> >>>       version.sh: fix version when built from tarball
> >>While you are about it, how about adding in this fix from Dieter Ries to fix
> >>version a little more:
> >>http://article.gmane.org/gmane.comp.file-systems.btrfs/20069
> >I did not notice it before, but Dieter's patch does not work when progs
> >are built from .git repository
> >
> >-echo "#define BTRFS_BUILD_VERSION \"Btrfs $v\"" >> .build-version.h
> >+echo "#define BTRFS_BUILD_VERSION \"$v\"" >> .build-version.h
> >
> >$v is set with the git tag, so the "Btrfs" string does not appear in the
> >output (eg. mkfs.btrfs).
> >
> >Technically, $v should always contain some sort of a tag, Sergei's patch
> >hardcodes it to the latest one for the non-git case. This is IMHO the
> >right approach.
> >
> OK, I see what you mean.  However, the current situation when btrfs
> is built from a tarball results in:
> 
> >btrfs  --version
> Btrfs Btrfs v0.19

   I guess one problem here is that there's no canonical way of
generating a tarball (without the git files) from a git checkout, with
detailed version information. So what's happening, I suspect, is that
the distributions/people producing source tarballs of btrfs-progs are
checking out the git tree, deleting .git, and tarring up that, which
loses any git versioning.

   I think a solution may be to have a "dist" or "tar" make target
which does the above automatically and includes a suitably-generated
version.h in the tarball.

   Hugo.

> and
> 
> >mkfs.btrfs  -V
> mkfs.btrfs, part of Btrfs Btrfs v0.19
> 
> There must be a way to reliably just have one "Btrfs" and I will
> look into it.
> 
> Gene

-- 
=== 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
    --- Klytus, I'm bored. What plaything can you offer me today? ---    

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

Re: [GIT PULL] btrfs-progs: more bugfixes for 0.20-rc1

[Gene Czarcinski]

On 01/18/2013 10:55 AM, Hugo Mills wrote:
> On Fri, Jan 18, 2013 at 10:49:20AM -0500, Gene Czarcinski wrote:
>> On 01/18/2013 09:44 AM, David Sterba wrote:
>>> On Fri, Jan 18, 2013 at 09:16:00AM -0500, Gene Czarcinski wrote:
>>>>> Sergei Trofimovich (1):
>>>>>        version.sh: fix version when built from tarball
>>>> While you are about it, how about adding in this fix from Dieter Ries to fix
>>>> version a little more:
>>>> http://article.gmane.org/gmane.comp.file-systems.btrfs/20069
>>> I did not notice it before, but Dieter's patch does not work when progs
>>> are built from .git repository
>>>
>>> -echo "#define BTRFS_BUILD_VERSION \"Btrfs $v\"" >> .build-version.h
>>> +echo "#define BTRFS_BUILD_VERSION \"$v\"" >> .build-version.h
>>>
>>> $v is set with the git tag, so the "Btrfs" string does not appear in the
>>> output (eg. mkfs.btrfs).
>>>
>>> Technically, $v should always contain some sort of a tag, Sergei's patch
>>> hardcodes it to the latest one for the non-git case. This is IMHO the
>>> right approach.
>>>
>> OK, I see what you mean.  However, the current situation when btrfs
>> is built from a tarball results in:
>>
>>> btrfs  --version
>> Btrfs Btrfs v0.19
>     I guess one problem here is that there's no canonical way of
> generating a tarball (without the git files) from a git checkout, with
> detailed version information. So what's happening, I suspect, is that
> the distributions/people producing source tarballs of btrfs-progs are
> checking out the git tree, deleting .git, and tarring up that, which
> loses any git versioning.
>
>     I think a solution may be to have a "dist" or "tar" make target
> which does the above automatically and includes a suitably-generated
> version.h in the tarball.
>
>     Hugo.
If you use gitweb to addess btrfs-progs.git, there is a very nice label 
"snapshot" beside each commit entry and clicking it will get you a 
tarball of the tree from that point.

I am a newbie at the git stuff but it seems to me that a few more 
branches are needed with stable branches marked as such and one or more 
unstable development branches ... at least that is what I have seen done 
on other projects such as NetworkManager and libvirt.  The branch will 
then include a hardcoded value for the version id which will/can be 
different in each branch.  And they also usually have a "make dist" 
which packages things up into a tarball.

The snapshot-tarball from gitweb includes the first part of the git 
commit id.  It is just that it is not included in a file.  The tarball 
does not includes only ".gitignore".  Rpms (and I assume the debian 
packages also) are based on tarball source with additional patches as 
necessary.  I have seen only one fedora package actually use git in the 
rpm and that was grub2.

While running stuff directly from a local git repository may be nice for 
developer, actual inclusion in a distribution package will (I believe) 
be via tarball.
>
>> and
>>
>>> mkfs.btrfs  -V
>> mkfs.btrfs, part of Btrfs Btrfs v0.19
>>
>> There must be a way to reliably just have one "Btrfs" and I will
>> look into it.
>>
As I was sitting here typing this message, the "solution" occurred to me:

Do not use Dieter's patch because it is unnecessary ... Sergei's patch 
does things correctly already.

Sorry for the noise on the list.  However, I do suggest that more git 
branches be used rather than having everything under "master".

Re: [GIT PULL] btrfs-progs: more bugfixes for 0.20-rc1

[David Sterba]

On Fri, Jan 18, 2013 at 10:33:18AM -0500, Gene Czarcinski wrote:
> I would like to recommend some additional patches for inclusion since they
> are currently part of the Fedora 18 btrfs-tools package.

Thanks. For now I'd like to gather all the small bugfixes and updates
that are likely not to create any significant conflicts with whatever
Chris has in his tree and skip new features, UI changes or non-obvious
fixes.

> Josef Bacik:  detect if the disk we are formatting is a ssd V2
> http://article.gmane.org/gmane.comp.file-systems.btrfs/18749

This is IMO a safe feature, the comments were addressed in the final
patch so we can try to push it.

> This one may be a little more of a problem since the suggested man update is
> missing and there is a second part for the kernel (status unknown).
> Josef Bacik:  add btrfs device ready command
> http://article.gmane.org/gmane.comp.file-systems.btrfs/18129
> Since Fedora uses a "stock" a kernel as possible, I suspect the
> corresponding patch is applied.

The kernel part of 'device ready' was merged to 3.6.

> There are two or three other patches that appear to make sense but I have no
> idea if they have been submitted.

Please send them to the list.

david

Re: [GIT PULL] btrfs-progs: more bugfixes for 0.20-rc1

[Goffredo Baroncelli]

Hi Chris,
On 01/17/2013 06:51 PM, Chris Mason wrote:
> On Thu, Jan 17, 2013 at 10:47:21AM -0700, David Sterba wrote:
>> Hi Chris,
>>
[...]
>
> Thanks Dave, pulling these in.
what about my patches "Enhance the command btrfs filesystem df" (see my 
emails dated on 2012/11/02) [1] ?
You stated an interesting in these patches; however then I never heard 
anything...

Do you want  I resubmit ? I reached a general consensus ( == nobody was 
too unsatisfied :-) ) about the wording and the format.

And I have another question: it is possible to access to the RAID5/6 
develop branch. I am interesting to check how my patches work with 
RAID5/6...



>
> -chris

BR
G.Baroncelli


[1] http://permalink.gmane.org/gmane.comp.file-systems.btrfs/21071
-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

Re: [GIT PULL] btrfs-progs: more bugfixes for 0.20-rc1

[Gene Czarcinski]

On 01/18/2013 12:22 PM, David Sterba wrote:
> On Fri, Jan 18, 2013 at 10:33:18AM -0500, Gene Czarcinski wrote:
>> I would like to recommend some additional patches for inclusion since they
>> are currently part of the Fedora 18 btrfs-tools package.
> Thanks. For now I'd like to gather all the small bugfixes and updates
> that are likely not to create any significant conflicts with whatever
> Chris has in his tree and skip new features, UI changes or non-obvious
> fixes.
>
>> Josef Bacik:  detect if the disk we are formatting is a ssd V2
>> http://article.gmane.org/gmane.comp.file-systems.btrfs/18749
> This is IMO a safe feature, the comments were addressed in the final
> patch so we can try to push it.
>
>> This one may be a little more of a problem since the suggested man update is
>> missing and there is a second part for the kernel (status unknown).
>> Josef Bacik:  add btrfs device ready command
>> http://article.gmane.org/gmane.comp.file-systems.btrfs/18129
>> Since Fedora uses a "stock" a kernel as possible, I suspect the
>> corresponding patch is applied.
> The kernel part of 'device ready' was merged to 3.6.
>
>> There are two or three other patches that appear to make sense but I have no
>> idea if they have been submitted.
> Please send them to the list.
>
Josef Bacik <josef@toxicpanda.com> is the current Fedora maintainer as 
indicated in bugzilla.
<mailto:josef@toxicpanda.com>
Currently in Fedora 18, btrfs-progs is the "v0.20-rc1 with git commit id 
<mailto:josef@toxicpanda.com>91d9eec" plus a total of seven patches.  
Two of those patches from the list which I have already indicated.  The 
rest of those patches have been around for a while (at least since mid 
2011) and I cannot find any doc.

While I could send them in (and will if needed), I feel a little uneasy 
since Josef is responsible in Fedora.  While this may be a different 
individual since the email address is different, I suspect this Josef is 
the same Josef who wrote the other two patches and he may be able to 
speak to them better.

I have been scraping mailing list for all of the btrfs-progs patches and 
plan to gradually test them.  Since it appears you will be doing 
something similar, if you want to point me to some for testing, I will 
give it a shot with some virtual and some real-iron testing.  And 
sometimes it is also a matter of the time needed to refit/rebase patches.

Gene

Re: [GIT PULL] btrfs-progs: more bugfixes for 0.20-rc1

[David Sterba]

On Fri, Jan 18, 2013 at 04:02:09PM -0500, Gene Czarcinski wrote:
> >Please send them to the list.
> >
> Josef Bacik <josef@toxicpanda.com> is the current Fedora maintainer as
> indicated in bugzilla.
> <mailto:josef@toxicpanda.com>
> Currently in Fedora 18, btrfs-progs is the "v0.20-rc1 with git commit id
> <mailto:josef@toxicpanda.com>91d9eec" plus a total of seven patches.  Two of
> those patches from the list which I have already indicated.  The rest of
> those patches have been around for a while (at least since mid 2011) and I
> cannot find any doc.
> 
> While I could send them in (and will if needed), I feel a little uneasy
> since Josef is responsible in Fedora.  While this may be a different
> individual since the email address is different, I suspect this Josef is the
> same Josef who wrote the other two patches and he may be able to speak to
> them better.

Sorry, I somehow assumed you were speaking on behalf of Fedora.

> I have been scraping mailing list for all of the btrfs-progs patches and
> plan to gradually test them.  Since it appears you will be doing something
> similar, if you want to point me to some for testing, I will give it a shot
> with some virtual and some real-iron testing.  And sometimes it is also a
> matter of the time needed to refit/rebase patches.

Great, thanks! Testing of the userspace utilities is relatively safe
(compared to the kernel module) and I'm using using the tool compiled
from the master+patches on my regular testboxes. So far no disasterous
problems encountered and I can immediatelly see if something goes wrong
during normal use of the tools.

Hugo once started a regression testsuite that should eg. verify sanity
of the option parsing, so extending these tests would be welcome.

http://git.darksatanic.net/cgi/gitweb.cgi?p=btrfs-progs-unstable.git;a=commit;h=c18d54a5bab5f5e0c6dc3c8cf4a1cc073e82f876


david