[PATCH RESEND 2/2] Correct allowed raid levels on balance.

[Andreas Philipp]

Raid5 with 3 devices is well defined while the old logic allowed
raid5 only with a minimum of 4 devices when converting the block group
profile via btrfs balance. Creating a raid5 with just three devices
using mkfs.btrfs worked always as expected. This is now fixed and the
whole logic is rewritten.

Signed-off-by: Andreas Philipp 
---
 fs/btrfs/volumes.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 8818dc3..6885165 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -3046,13 +3046,12 @@ int btrfs_balance(struct btrfs_balance_control
*bctl,
allowed = BTRFS_AVAIL_ALLOC_BIT_SINGLE;
if (num_devices == 1)
allowed |= BTRFS_BLOCK_GROUP_DUP;
-   else if (num_devices < 4)
+   if (num_devices > 1)
allowed |= (BTRFS_BLOCK_GROUP_RAID0 | BTRFS_BLOCK_GROUP_RAID1);
-   else
-   allowed |= (BTRFS_BLOCK_GROUP_RAID0 | BTRFS_BLOCK_GROUP_RAID1 |
-   BTRFS_BLOCK_GROUP_RAID10 |
-   BTRFS_BLOCK_GROUP_RAID5 |
-   BTRFS_BLOCK_GROUP_RAID6);
+   if (num_devices > 2)
+   allowed |= BTRFS_BLOCK_GROUP_RAID5;
+   if (num_devices > 3)
+   allowed |= (BTRFS_BLOCK_GROUP_RAID10 | BTRFS_BLOCK_GROUP_RAID6);
if ((bctl->data.flags & BTRFS_BALANCE_ARGS_CONVERT) &&
(!alloc_profile_is_valid(bctl->data.target, 1) ||
-- 
1.7.12.4

--
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

[PATCH RESEND 1/2] Minor format cleanup.

[Andreas Philipp]

Clean up the format of the definitions of BTRFS_BLOCK_GROUP_RAID5 and
BTRFS_BLOCK_GROUP_RAID6.

Signed-off-by: Andreas Philipp 
---
 fs/btrfs/ctree.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index e3a4fd7..ea688aa 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -954,8 +954,8 @@ struct btrfs_dev_replace_item {
 #define BTRFS_BLOCK_GROUP_RAID1(1ULL << 4)
 #define BTRFS_BLOCK_GROUP_DUP  (1ULL << 5)
 #define BTRFS_BLOCK_GROUP_RAID10   (1ULL << 6)
-#define BTRFS_BLOCK_GROUP_RAID5(1 << 7)
-#define BTRFS_BLOCK_GROUP_RAID6(1 << 8)
+#define BTRFS_BLOCK_GROUP_RAID5 (1ULL << 7)
+#define BTRFS_BLOCK_GROUP_RAID6 (1ULL << 8)
 #define BTRFS_BLOCK_GROUP_RESERVED BTRFS_AVAIL_ALLOC_BIT_SINGLE
 #define BTRFS_NR_RAID_TYPES7
 -- 1.7.12.4

--
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

[PATCH RESEND 0/2] Two small patches for the raid56 code

[Andreas Philipp]

Hi,

The last few days I have been playing around with Chris Mason's
raid56-experimental branch (Thanks!) and discovered two minor issues.

Thanks,
Andreas

Andreas Philipp (2):
  Minor format cleanup.
  Correct allowed raid levels on balance.

 fs/btrfs/ctree.h   |  4 ++--
 fs/btrfs/volumes.c | 11 +--
 2 files changed, 7 insertions(+), 8 deletions(-)

-- 
1.7.12.4

--
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: Btrfs balance invalid argument error

[Andreas Philipp]

On 05/10/2013 11:46 PM, Hugo Mills wrote:
> On Fri, May 10, 2013 at 11:43:34PM +0200, Marcus Lövgren wrote:
>> Yes, you were right! Adding another drive to the array made it continue
>> without errors. Is this already reported as a bug?
>
>I believe it has been, yes. I think we've even had a patch out for
> it. I haven't looked to see if it's got into 3.10.
>
Yes, there is a patch but as far as I've seen it didn't hit 3.10 (yet).
I'll repost it immediately.

Thanks for reminding me on that,
Andreas

>Hugo.
>
>> Thanks for the help,
>> Marcus
>>
>>
>> 2013/5/10 Remco Hosman - Yerf IT 
>>
>>> On May 10, 2013, at 10:21 PM, Hugo Mills  wrote:
>>>
 On Fri, May 10, 2013 at 10:07:56PM +0200, Marcus Lövgren wrote:
> Hi list,
>
> I am using kernel 3.9.0, btrfs-progs 0.20-rc1-253-g7854c8b.
>
> I have a three disk array of level single:
>
> # btrfs fi sh
> Label: none  uuid: 2e905f8f-e525-4114-afa6-cce48f77b629
>Total devices 3 FS bytes used 3.80TB
>devid1 size 2.73TB used 2.25TB path /dev/sdd
>devid2 size 2.73TB used 1.55TB path /dev/sdc
>devid3 size 2.73TB used 0.00 path /dev/sdb
>
> Btrfs v0.20-rc1-253-g7854c8b
>
> # btrfs fi df /mnt/data
> Data: total=3.79TB, used=3.79TB
> System: total=4.00MB, used=420.00KB
> Metadata: total=6.01GB, used=4.87GB
>
>
> When running
> # btrfs balance start -dconvert=raid5 -mconvert=raid5 /mnt/data
>
> I get
>
> ERROR: error during balancing '/mnt/data' - Invalid argument
> There may be more info in syslog - try dmesg | tail
>
> dmesg | tail says:
>
> btrfs: unable to start balance with target data profile 128
>
> Isn't it possible to convert raid level to raid5?

   Yes, it should be possible. It looks like the kernel's got a
 problem with it, which is odd because 3.9 should know about RAID-5.

>>>
>>> Wasn't there some issues that the kernel or tools wanted 4 disks when
>>> converting to raid5?
>>>
>>> Remco
>>>
   Hugo.

>


--
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

[PATCH 0/2] Two small patches for the raid56 code

[Andreas Philipp]

Hi,

The last few days I have been playing around with Chris Mason's
raid56-experimental branch (Thanks!) and discovered two minor issues.

Thanks,
Andreas

Andreas Philipp (2):
  Minor format cleanup.
  Correct allowed raid levels on balance.

 fs/btrfs/ctree.h   |  4 ++--
 fs/btrfs/volumes.c | 11 +--
 2 files changed, 7 insertions(+), 8 deletions(-)

-- 
1.7.12.4

--
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: RAID 5/6

[Andreas Philipp]

On 10/22/2012 06:05 PM, Hugo Mills wrote:
> On Mon, Oct 22, 2012 at 10:58:07AM -0500, Michael wrote:
>> Does anyone know when RAID 5/6 are planned to be included in the
>> Kernel?
>
> This is in the FAQ:
>
>
https://btrfs.wiki.kernel.org/index.php/FAQ#Can_I_use_RAID.5B56.5D_on_my_Btrfs_filesystem.3F
>
> Short answer: Not yet, probably soon.
>
>> I am starting to buy parts for my next computer and would very
>> much like to use BTRFS because I want a FS that can grow and also
>> recover from undetected read errors - it will be large enough that
>> these are possible. I'm hoping that it will be available for use in
>> the coming months.
>
> You can switch storage types on the fly, so you could at least
> start with RAID-1, and then restripe to RAID-5 (or -6) when it's
> stable enough for you. This assumes that you can manage to use RAID-1
> in the first place and expand later.
If you can live without redundancy at the beginning, you could also
start with RAID-0, and then restripe to RAID-5.

Andreas

--
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: Cannot create subvolume with quota enabled

[Andreas Philipp]

2012/9/10 Arne Jansen :
> On 09/10/2012 08:13 PM, Andreas Philipp wrote:
>> Hi Arne,
>>
>> On 08.09.2012 00:04, Arne Jansen wrote:
>>> Hi Andreas,
>>>
>>> On 09/07/2012 09:36 PM, Andreas Philipp wrote:
>>>> Hi,
>>>>
>>>> The following steps reproduce the error. My kernel is 3.6-rc4 and
>>>> btrfs-progs are at commit 89fe5b5f666c247aa3173745fb87c710f3a71a4a
>>>> from
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git
>>>>
>>>>
>>> master.
>>>> thor ~ # mkfs.btrfs -L test /dev/vg1/test
>>>>
>>>> WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL WARNING! - see
>>>> http://btrfs.wiki.kernel.org before using
>>>>
>>>> fs created label test on /dev/vg1/test nodesize 4096 leafsize 4096
>>>> sectorsize 4096 size 20.00GB Btrfs Btrfs v0.19 thor ~ # mount
>>>> /dev/vg1/test /mnt/tmp thor ~ # btrfs quota enable /mnt/tmp thor ~
>>>> # btrfs subvolume create /mnt/tmp/test Create subvolume
>>>> '/mnt/tmp/test' ERROR: cannot create subvolume - Invalid argument
>>> Thanks for giving quota a try. I sent a fix separately with
>>> the subject
>>>
>>> [PATCH] Btrfs: btrfs_qgroup_inherit wrongly returns an error
>>>
>>> Could you please see if it fixes the problem?
>> With the patch applied (on top of either 3.6-rc4 or 3.6-rc5) I can
>> create subvolumes as you see below.
>>
>> root@debian:~# mkfs.btrfs /dev/sdb
>>
>> WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
>> WARNING! - see http://btrfs.wiki.kernel.org before using
>>
>> fs created label (null) on /dev/sdb
>> nodesize 4096 leafsize 4096 sectorsize 4096 size 3.00GB
>> Btrfs Btrfs v0.19
>> root@debian:~# mount /dev/sdb /mnt/test
>> root@debian:~# btrfs quota enable /mnt/test
>> root@debian:~# btrfs subvolume create /mnt/test/subvolume
>> Create subvolume '/mnt/test/subvolume'
>> root@debian:~# btrfs qgroup show /mnt/test
>> 0/257 4096 4096
>> root@debian:~# dd if=/dev/urandom of=/mnt/test/subvolume/testfile
>> bs=1024k count=25
>> 25+0 records in
>> 25+0 records out
>> 26214400 bytes (26 MB) copied, 2.95321 s, 8.9 MB/s
>> root@debian:~# btrfs qgroup show /mnt/test
>> 0/257 4096 4096
>> root@debian:~# du -hs /mnt/test/*
>> 25M /mnt/test/subvolume
>>
>> At least I expected that the output of ' btrfs qgroup show' changes
>> after some data got written to a subvolume which is assigned to a
>> qgroup. (Hope, I got it right.)
>
> due to delayed-*, the accounting also sometimes shows up delayed.
> After a sync you should see the changes.

Sorry, I forgot to check with umount & mount or sync. It works.

Thanks,
Andreas

>
>>
>> Thanks,
>> Andreas
>>
>>>
>>> Thanks,
>>> Arne
>>>> Please, do not hesitate to contact me for any further information
>>>> etc.
>>>>
>>>> Thanks, Andreas -- 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
>>
>
--
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: Cannot create subvolume with quota enabled

[Andreas Philipp]

Hi Arne,

On 08.09.2012 00:04, Arne Jansen wrote:
> Hi Andreas,
>
> On 09/07/2012 09:36 PM, Andreas Philipp wrote:
>> Hi,
>>
>> The following steps reproduce the error. My kernel is 3.6-rc4 and 
>> btrfs-progs are at commit 89fe5b5f666c247aa3173745fb87c710f3a71a4a
>> from 
>> git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git
>>
>>
> master.
>> thor ~ # mkfs.btrfs -L test /dev/vg1/test
>>
>> WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL WARNING! - see
>> http://btrfs.wiki.kernel.org before using
>>
>> fs created label test on /dev/vg1/test nodesize 4096 leafsize 4096
>> sectorsize 4096 size 20.00GB Btrfs Btrfs v0.19 thor ~ # mount
>> /dev/vg1/test /mnt/tmp thor ~ # btrfs quota enable /mnt/tmp thor ~
>> # btrfs subvolume create /mnt/tmp/test Create subvolume
>> '/mnt/tmp/test' ERROR: cannot create subvolume - Invalid argument
> Thanks for giving quota a try. I sent a fix separately with
> the subject
>
> [PATCH] Btrfs: btrfs_qgroup_inherit wrongly returns an error
>
> Could you please see if it fixes the problem?
With the patch applied (on top of either 3.6-rc4 or 3.6-rc5) I can
create subvolumes as you see below.

root@debian:~# mkfs.btrfs /dev/sdb

WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

fs created label (null) on /dev/sdb
nodesize 4096 leafsize 4096 sectorsize 4096 size 3.00GB
Btrfs Btrfs v0.19
root@debian:~# mount /dev/sdb /mnt/test
root@debian:~# btrfs quota enable /mnt/test
root@debian:~# btrfs subvolume create /mnt/test/subvolume
Create subvolume '/mnt/test/subvolume'
root@debian:~# btrfs qgroup show /mnt/test
0/257 4096 4096
root@debian:~# dd if=/dev/urandom of=/mnt/test/subvolume/testfile
bs=1024k count=25
25+0 records in
25+0 records out
26214400 bytes (26 MB) copied, 2.95321 s, 8.9 MB/s
root@debian:~# btrfs qgroup show /mnt/test
0/257 4096 4096
root@debian:~# du -hs /mnt/test/*
25M /mnt/test/subvolume

At least I expected that the output of ' btrfs qgroup show' changes
after some data got written to a subvolume which is assigned to a
qgroup. (Hope, I got it right.)

Thanks,
Andreas

>
> Thanks,
> Arne
>> Please, do not hesitate to contact me for any further information
>> etc.
>>
>> Thanks, Andreas -- 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

Cannot create subvolume with quota enabled

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

The following steps reproduce the error. My kernel is 3.6-rc4 and
btrfs-progs are at commit 89fe5b5f666c247aa3173745fb87c710f3a71a4a from
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git
master.

thor ~ # mkfs.btrfs -L test /dev/vg1/test

WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

fs created label test on /dev/vg1/test
nodesize 4096 leafsize 4096 sectorsize 4096 size 20.00GB
Btrfs Btrfs v0.19
thor ~ # mount /dev/vg1/test /mnt/tmp
thor ~ # btrfs quota enable /mnt/tmp
thor ~ # btrfs subvolume create /mnt/tmp/test
Create subvolume '/mnt/tmp/test'
ERROR: cannot create subvolume - Invalid argument

Please, do not hesitate to contact me for any further information etc.

Thanks,
Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQEcBAEBAgAGBQJQSky/AAoJEIW3W1BiBxU7/AIH/0K+FRSFl619SKnSrpiib+wk
5Rf+R9mjMn9yateRbhtblBF5KuWfGELO8w7okf6Mg6L/wCD7fYFuwo8Gwm7RvG/T
lBrOCRPvrdkT78+elX/Jaj1QKWcYkTz7bkpcXf57zdzLruO1VwF0aCQZOFDR/qD2
d3oI5OCc/3Qw9G0ZnqV/z+bT3oqJRPJBV4ihB1SSI+5YpCAtHBW1jFGfwWRuA+ZV
Q+iPPjMKZALG6wQYu+4WG5M1l9pC9y/aRetBfWplQTVgfT4Hh3eZjvq6OnDv9ZiO
rWLSTqG0uBRCW2Sws0uFpPKMod0RFWm0sJNfkzGAM6O3a15CGTPnA9Hq0SgMRL4=
=pr3t
-END PGP SIGNATURE-
--
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: No SysRq remount because sb->s_bdev is NULL

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 

On 28.07.2012 16:50, Florian Albrechtskirchinger wrote:
> On Saturday, July 28, 2012 15:46:50 Andreas Philipp wrote:
>> On 28.07.2012 15:41, Florian Albrechtskirchinger wrote:
>>> During a SysRq emergency remount Btrfs mounts are not remounted. I
tracked
>>> the issue down to this line in do_emergency_remount() in fs/super.c:
>>> if (sb->s_root && sb->s_bdev && (sb->s_flags & MS_BORN) &&
>>> !(sb->s_flags & MS_RDONLY))
>>> s_bdev is NULL for Btrfs super blocks and subsequently
do_remount_sb() is
>>> never called. I couldn't think of a solution, besides resorting to
an ugly
>>> strcmp(sb->s_type->name, "btrfs"), without adding a field to struct
>>> super_block or similar changes.
>>> Thoughts?
>>
>> Just a first thought. Is there a possibility to write a dummy value into
>> sb->s_bdev for btrfs super blocks. Thus it will not be NULL and
>> everything in do_emergency_remount() in fs/super.c will work as wanted.
>
> Then other code paths testing sb->s_bdev for NULL and assuming a
non-NULL sb-
>> s_bdev is a valid block device would fail.
Sorry, I thought that there are separate checks whether the value of
sb->s_bdev is a valid block device.
Thanks,
Andreas
>>
>
> Flo

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQEcBAEBAgAGBQJQFBOrAAoJEIW3W1BiBxU7xCsH/RzDyJR7MneXLtDBQIQC43XS
+jdaMrUIjEjBhs390iJJWebg5H6690XEO/wSM36ZMkHi0fSeJ7dC4WKjTtLyTkAB
ok2+1Qix2LcqWxGSr9TC5OAjli3A8bl2Iy+P3bObfVOYnaTS781+ALl2PopiyZva
ineLrXzGiUQoT059BK456ckceNkQ31YTbuwAEVP85ZdC4Bk8UviUYdoVtsFBb2aH
4UnHgnGdrPhz6BqIbxhrfTLNsNbnGskQ8MrxogRChv+P1SRKHslBKTLCvXugH5t4
iwrXtm1gtpFDWkmiMfYN6HpV/vGIrqstUns7zj/kYVbC2c0u4QGBSZLhy9S7UF4=
=1I+D
-END PGP SIGNATURE-

--
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: No SysRq remount because sb->s_bdev is NULL

[Andreas Philipp]

Hi,

Just a first thought. Is there a possibility to write a dummy value into
sb->s_bdev for btrfs super blocks. Thus it will not be NULL and
everything in do_emergency_remount() in fs/super.c will work as wanted.

Thanks,
Andreas


On 28.07.2012 15:41, Florian Albrechtskirchinger wrote:
> Hi,
>
> During a SysRq emergency remount Btrfs mounts are not remounted. I tracked 
> the 
> issue down to this line in do_emergency_remount() in fs/super.c:
> if (sb->s_root && sb->s_bdev && (sb->s_flags & MS_BORN) &&
>   !(sb->s_flags & MS_RDONLY))
> s_bdev is NULL for Btrfs super blocks and subsequently do_remount_sb() is 
> never called. I couldn't think of a solution, besides resorting to an ugly 
> strcmp(sb->s_type->name, "btrfs"), without adding a field to struct 
> super_block 
> or similar changes.
> Thoughts?
>
> Flo
> --
> 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: btrfs_print_tree?

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 

On 01.07.2012 12:16, Jeff Liu wrote:
> On 07/01/2012 05:49 PM, Zhi Yong Wu wrote:
>
>> On Sun, Jul 1, 2012 at 5:41 PM, Mike Fleetwood
>>  wrote:
>>> On 1 July 2012 05:53, Zhi Yong Wu  wrote:
 HI,

 Do anyone know where btrfs_print_tree is invoked? thanks.

 --
 Regards,

 Zhi Yong Wu
>>>
>>> Is this the answer you are after?
>>>
>>> $ grep -r btrfs_print_tree fs/btrfs/
>>> fs/btrfs/print-tree.c:void btrfs_print_tree(struct btrfs_root *root,
>>> struct extent_buffer *c)
>>> fs/btrfs/print-tree.c: btrfs_print_tree(root, next);
>>> fs/btrfs/print-tree.h:void btrfs_print_tree(struct btrfs_root *root,
>>> struct extent_buffer *t);
>> No, i also did as this, but didn't find out who will invoke this
>> function. From above output, we only saw that it invokes itself one
>> time.
>
> Looks this is a helper routine exported to btrfs-progs previously, it is
> used by debug-tree, quick-test, etc...
>
> But this function has been implemented at btrfs-progs now, maybe it
> could be safely removed from kernel, not sure. :)
>
> Thanks,
> -Jeff
Looks exactly the same to me.

Thanks,
Andreas

>
>
>>
>>>
>>> Mike
>>
>>
>>
>
>
> --
> 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


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQEcBAEBAgAGBQJP8CVUAAoJEIW3W1BiBxU7RMMH/A90pUdpILSWJndkJiddmbqW
17SyQMldS/xSFVHvT8ot92jyKqYhk6MFGwdkGgCX8RXCO5G5PzbxOGHxtF3j872V
J3fPp9qxTpNSEhy7uDsnyMvDFgNgXWNxz61G6ISZrubd0M0rTRdd77DrYLOqgwiQ
uTOwQ8WGPB+jOPb6+8URcPzyD82uUejIQKS4svmffPSQMY8gJEz5408HFB6SIyf/
+5/UUXwRYOlbNAVjiOVVhHWvrm1MDI1hD0S8duy2/TsS/cEt/d6xrWIJ9Ky2468y
Q62PRf6hu3GI3yxfNrEDn5i6vRVI/0EMzJHna56r1NApqa1jIIJFVbo53UyjnGw=
=3Dqd
-END PGP SIGNATURE-

--
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: btrfs_print_tree?

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 01.07.2012 11:49, Zhi Yong Wu wrote:
> On Sun, Jul 1, 2012 at 5:41 PM, Mike Fleetwood
>  wrote:
>> On 1 July 2012 05:53, Zhi Yong Wu  wrote:
>>> HI,
>>>
>>> Do anyone know where btrfs_print_tree is invoked? thanks.
>>>
>>> --
>>> Regards,
>>>
>>> Zhi Yong Wu
>>
>> Is this the answer you are after?
>>
>> $ grep -r btrfs_print_tree fs/btrfs/
>> fs/btrfs/print-tree.c:void btrfs_print_tree(struct btrfs_root *root,
>> struct extent_buffer *c)
>> fs/btrfs/print-tree.c: btrfs_print_tree(root, next);
>> fs/btrfs/print-tree.h:void btrfs_print_tree(struct btrfs_root *root,
>> struct extent_buffer *t);
> No, i also did as this, but didn't find out who will invoke this
> function. From above output, we only saw that it invokes itself one
> time.
Is this function unused then?

Andreas
>
>
>>
>> Mike
>
>
>


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQEcBAEBAgAGBQJP8CNFAAoJEIW3W1BiBxU7C40H/0ecIgo1AagGyh/q4tLjXxAZ
PILqpKZzGiX6Qc+qWnaHrNyCJU1ntppO73k/SmhMpx+xycw/qHbqKtCpw/W8aQfn
ihKOP9amgCUR/X+1W7hn190r0c1teWnXV/bYoD81fksWYuZmG9XzBOF4u9iLrtIb
0hpeBtFPr7jizKv3puOVKBpEV3ZMUdiqwc+G5GxUSlOssqKdF38gHGvj1k3j1qTX
0JRndsaeZq0smA0RJnYa9nX7gvg8CnmUXIJ/yLgg8Rnn5LhJQoq2eK4fgE+I0OCy
SjlzSQG78W9CnWmE6SitfVeb/QUyLdCZ/mtwPxqeKd9p06hcLCU4R89rWRnNWTQ=
=bq50
-END PGP SIGNATURE-

--
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: Can't write much data on a degraded mirror

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Hi,

Is there any way to willingly write more data to a degraded array? There
are other use cases for such a possibility as well. Just think of
migrating from software raid (and lvm) based setup.

Thanks,
Andreas Philipp

On 03.02.2012 20:17, Lutz Euler wrote:
> Hi,
>
> Btrfs seems not to want to allocate new chunks on a degraded mirror,
> severely restricting the amount of new data that can be written to such
> a filesystem. I hope this is not intentional? It makes mirroring much
> less useful than it could be, at least for me.
>
> My use case: I want to use btrfs with two mirrored disks on a desktop
> machine. Lets say the filesystem is far from full. Assume one disk
> fails, I send it in for RMA and have to wait 6 weeks for a replacement.
> I could live without the mirror redundancy during this time but not
> without the ability to store more data on the filesystem.
>
> I would prefer if btrfs remembered the size of the missing device and
> allowed to allocate space on the degraded mirror until the capacity is
> reached that the nondegraded mirror had.
>
> Here is how to reproduce the effect:
>
> Create and mount a mirror of two 20 GB devices:
>
> # dd if=/dev/zero of=/tmp/img0 bs=1 count=0 seek=20G
> # dd if=/dev/zero of=/tmp/img1 bs=1 count=0 seek=20G
> # losetup -f /tmp/img0
> # losetup -f /tmp/img1
> # losetup -a
> /dev/loop0: [0802]:1441845 (/tmp/img0)
> /dev/loop1: [0802]:1441856 (/tmp/img1)
> # mkfs.btrfs -d raid1 -m raid1 /dev/loop0 /dev/loop1
> # mount /dev/loop0 /mnt
> # df -h /mnt
> Dateisystem Size Used Avail Use% Eingehängt auf
> /dev/loop0 40G 56K 38G 1% /mnt
>
> Umount, make one device unavailable and mount degraded:
>
> # umount /mnt
> # losetup -d /dev/loop1
> # mount -o degraded /dev/loop0 /mnt
> # df -h /mnt
> Dateisystem Size Used Avail Use% Eingehängt auf
> /dev/loop0 40G 312K 2,0G 1% /mnt
>
> Notice that the "Avail" value has shrunk drastically; it seems
> to show only the space available in already allocated chunks.
> Now, "df" might simply lie, so let's try to put data on the filesystem:
>
> # dd if=/dev/zero of=/mnt/data bs=4K count=512K
>
> -> ENOSPC after writing 1.1 GB
>
> The software used is:
>
> Kernel: v3.3-rc1-383-g0a96265
> uname -a: Linux test 3.3.0-rc1 #1 SMP PREEMPT Sun Jan 29 16:06:29 CET
> 2012 x86_64 x86_64 x86_64 GNU/Linux
> btrfs-progs: cloned on 2012-01-25 from
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git,
> latest commit is fdb6c0402337d9607c7a39155088eaf033742752.
> OS: Ubuntu 11.04.
>
> Kind regards,
>
> Lutz
> --
> 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
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQEcBAEBAgAGBQJPW5sMAAoJEIW3W1BiBxU7WaQIAI3BgB5zbfxzMKKyhlEzdjwR
2faI539BuTSz3RVpoCn8BMREVJSvfDcdT40uIV+io53IW5/0AgH8y0Tlg5HTmm5V
XtGtbT8MFpnQvSvUoWVJdDiIhlo1BNhL3KBVm5dXHQEkeviQZs1RZ0ndI1IKlnnB
gIZEYRJpb9ig9RI2HKlhKRPWDiTSyWBTEL0HuteY7jmISThCGTvnAq1b6A/mSVq6
CQvHnk7h1LbCvBBUvIxUUJewrfdnspqiGR95hAA9RGSQP7iAu7nMmi1rY0vw3cmF
+aF6r5eljvwmmdB/msDomaBYgWuf6RBV2aMZvmXigeU/g1tSbWRn3El8dBnqDZM=
=xi/2
-END PGP SIGNATURE-

--
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: [PATCH] Re: [btrfs-progs integration] incorrect argument checking for "btrfs sub snap -r"

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Hi,
 
You are right. Some time ago I have already sent a patch for this. Hugo,
can you please integrate it?
Thanks,
Andreas Philipp
 
[PATCH] check number of args for btrfs sub snap correctly
 
Check whether there are the right number of arguments (exatly 2 without
the flag -r) in the subcommand handler for the btrfs subvolume snapshot
command.
 
Signed-off-by: Andreas Philipp 
- ---
 btrfs_cmds.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
 
diff --git a/btrfs_cmds.c b/btrfs_cmds.c
index da5bd91..42c82f8 100644
- --- a/btrfs_cmds.c
+++ b/btrfs_cmds.c
@@ -354,7 +354,7 @@ int do_clone(int argc, char **argv)
 return 1;
 }
 }
- -if (argc - optind < 2) {
+if (argc - optind != 3) {
 fprintf(stderr, "Invalid arguments for subvolume snapshot\n");
 free(argv);
 return 1;
 
- --   
1.7.3.4
 
 
 
On 11.08.2011 06:30, Tsutomu Itoh wrote: 
> Hi, Hugo,
>
> I built your for-chris branch, and ran 'btrfs sub snap' command.
> Then, I encountered following error message.
>
> # btrfs sub snap Dir-1 Dir-2
> Invalid arguments for subvolume snapshot
>
> commit:8b4c2a22bff85f86af44587973c8da8c29a67ffc is wrong, I think.
>
> (2011/07/01 21:55), Stephane Chazelas wrote:
>> 2011-07-01 11:42:23 +0100, Hugo Mills:
>> [...]
>>>>> diff --git a/btrfs.c b/btrfs.c
>>>>> index e117172..b50c58a 100644
>>>>> --- a/btrfs.c
>>>>> +++ b/btrfs.c
>>>>> @@ -49,7 +49,7 @@ static struct Command commands[] = {
>>>>> /*
>>>>> avoid short commands different for the case only
>>>>> */
>>>>> - { do_clone, 2,
>>>>> + { do_clone, -2,
>>>>> "subvolume snapshot", "[-r]  [/]\n"
>>>>> "Create a writable/readonly snapshot of the subvolume  with\n"
>>>>> "the name  in the  directory.",
>>>>> diff --git a/btrfs_cmds.c b/btrfs_cmds.c
>>>>> index 1d18c59..3415afc 100644
>>>>> --- a/btrfs_cmds.c
>>>>> +++ b/btrfs_cmds.c
>>>>> @@ -355,7 +355,7 @@ int do_clone(int argc, char **argv)
>>>>> return 1;
>>>>> }
>>>>> }
>>>>> - if (argc - optind < 2) {
>>>>> + if (argc - optind != 2) {
>>>>> fprintf(stderr, "Invalid arguments for subvolume snapshot\n");
>>>>> free(argv);
>>>>> return 1;
>>>>>
>>>> Thanks for having another look at this. You are perfectly right. Should
>>>> we patch my patch or should I rework a corrected version? What do you
>>>> think Hugo?
>>> Could you send a follow-up patch with just the second hunk, please?
>>> I screwed up the process with this (processing patches too quickly to
>>> catch the review), and I've already published the patch with the first
>>> hunk, above, into the for-chris branch.
>> Hugo, not sure what you mean nor whom you're talking to, but I
>> can certainly copy-paste the second hunk from above here:
>>
>> diff --git a/btrfs_cmds.c b/btrfs_cmds.c
>> index 1d18c59..3415afc 100644
>> --- a/btrfs_cmds.c
>> +++ b/btrfs_cmds.c
>> @@ -355,7 +355,7 @@ int do_clone(int argc, char **argv)
>> return 1;
>> }
>> }
>> - if (argc - optind < 2) {
>> + if (argc - optind != 2) {
> I think that '3' is correct.
>
> Thanks,
> Tsutomu
>
>> fprintf(stderr, "Invalid arguments for subvolume snapshot\n");
>> free(argv);
>> return 1;
>>
>> Cheers,
>> Stephane
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJOQ3qTAAoJEJIcBJ3+XkgiYTsP/jS8jZoQQoVzpLClfQ4+xIbh
T1DLiEsu92fy+vxRSEUiFpSUcNlv6qfczwlOwmzWpWk/Cs01RP/XzBPAQc8qqZDy
JcEHq1Iteix9r9f7kMw2kA2UuRXrtuEiKjAYAOzp8OFoWHLB+S8yV1ajsRa9THOX
wZ+8wUkNuBfNFjJmwtirNpU0XJwm2QHVAI9n+7jj9asNVedY5tt6vw0YtFVpy2zS
FxUmGVoo+9+BAEiYkpZ9uvtXUNLojTwyFjMwbH4QAzJWrLTrMhXlj+SRS52mKt9Z
+Sr71QcIdhy+bb4oBDCjwB1SV9qyAoHTUs1yETzNRPAUgdnX41gZ6q/FYBDplmwZ
wLNiIa5MjO63SMN32CzLPQn/WbCzWIuGFkoYaBPYQu1ig7xZ3GulCmzhOqWMRfLn
FcN9GKF/LDcjaey9eTtgrZSp+Q+lRgsHbgg/2aMjZiGMYjOq/+EcFWXA9JfHQqSo
anQJU9WyUd4eO0ZYFMdRYeH81/+U6UktQVViQF4G9KbV3lbu3WQHhbbdFe2i7FXH
hWhaUdSEd6JmdKQWgqlV5XWo0hgMLO04oP8S5V03zEH6n5J4YU1wHDpZvsZTQbe8
3+k0far4o48GbcjUrMeRBkEuJiMOjNIHBXhjx5IAWkFGAQXvU29VA0IJ/XLFKjLA
0RhnC+XwTuaMSTYDzdxP
=oQbK
-END PGP SIGNATURE-

--
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: [PATCH V2] Btrfs-progs: add "btrfs subvolume get-default" subcommand

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Would you mind rebasing your patch on Hugo Mills' integration-branch for
btrfs progs at
http://git.darksatanic.net/repo/btrfs-progs-unstable.git
integration-20110705
since it does not apply on top of all changes which are already there.
Additionally, I spotted one whitespace error in the patch and marked it
below.
 
Thanks,
Andreas Philipp
 
On 11.07.2011 10:56, Zhong, Xin wrote:
> Add subcommand to get the default subvolume of btrfs filesystem
>
> Reported-by: Yang, Yi 
> Signed-off-by: Zhong, Xin 
> ---
> btrfs-list.c | 57
+++--
> btrfs.c | 3 +++
> btrfs_cmds.c | 31 ++-
> btrfs_cmds.h | 3 ++-
> 4 files changed, 90 insertions(+), 4 deletions(-)
>
> diff --git a/btrfs-list.c b/btrfs-list.c
> index 93766a8..aa6a9b4 100644
> --- a/btrfs-list.c
> +++ b/btrfs-list.c
> @@ -536,7 +536,7 @@ build:
> return full;
> }
>
> -int list_subvols(int fd)
> +int list_subvols(int fd, int get_default)
> {
> struct root_lookup root_lookup;
> struct rb_node *n;
> @@ -545,10 +545,12 @@ int list_subvols(int fd)
> struct btrfs_ioctl_search_key *sk = &args.key;
> struct btrfs_ioctl_search_header *sh;
> struct btrfs_root_ref *ref;
> + struct btrfs_dir_item *di;
> unsigned long off = 0;
> int name_len;
> char *name;
> u64 dir_id;
> + u64 subvol_id = 0;
> int i;
>
> root_lookup_init(&root_lookup);
> @@ -642,6 +644,52 @@ int list_subvols(int fd)
> n = rb_next(n);
> }
>
> + memset(&args, 0, sizeof(args));
> +
> + /* search in the tree of tree roots */
> + sk->tree_id = BTRFS_ROOT_TREE_OBJECTID;
> +
> + /* search dir item */
> + sk->max_type = BTRFS_DIR_ITEM_KEY;
> + sk->min_type = BTRFS_DIR_ITEM_KEY;
> +
> + sk->max_objectid = BTRFS_ROOT_TREE_DIR_OBJECTID;
> + sk->min_objectid = BTRFS_ROOT_TREE_DIR_OBJECTID;
> + sk->max_offset = (u64)-1;
> + sk->max_transid = (u64)-1;
> +
> + /* just a big number, doesn't matter much */
> + sk->nr_items = 4096;
> +
> + /* try to get the objectid of default subvolume */
> + if(get_default) {
> + ret = ioctl(fd, BTRFS_IOC_TREE_SEARCH, &args);
> + if (ret < 0) {
> + fprintf(stderr, "ERROR: can't perform the search\n");
> + return ret;
> + }
> +
> + off = 0;
> + /* go through each item to find dir item named "default" */
> + for (i = 0; i < sk->nr_items; i++) {
> + sh = (struct btrfs_ioctl_search_header *)(args.buf +
> + off);
> + off += sizeof(*sh);
> + if (sh->type == BTRFS_DIR_ITEM_KEY) {
> + di = (struct btrfs_dir_item *)(args.buf + off);
> + name_len = le16_to_cpu(di->name_len);
> + name = (char *)di + sizeof(struct btrfs_dir_item);
> + if (!strncmp("default", name, name_len)) {
> + subvol_id = btrfs_disk_key_objectid(
> + &di->location);
> + break;
> + }
> + }
> +
> + off += sh->len;
> + }
> + }
> +
> /* now that we have all the subvol-relative paths filled in,
> * we have to string the subvols together so that we can get
> * a path all the way back to the FS root
> @@ -650,7 +698,12 @@ int list_subvols(int fd)
> while (n) {
> struct root_info *entry;
> entry = rb_entry(n, struct root_info, rb_node);
> - resolve_root(&root_lookup, entry);
> + if(!get_default)
> + resolve_root(&root_lookup, entry);
> + /* we only want the default subvolume */
> + else if(subvol_id == entry->root_id)
> + resolve_root(&root_lookup, entry);
> +
This line adds a whitespace error.
> n = rb_prev(n);
> }
>
> diff --git a/btrfs.c b/btrfs.c
> index 46314cf..6b73f88 100644
> --- a/btrfs.c
> +++ b/btrfs.c
> @@ -73,6 +73,9 @@ static struct Command commands[] = {
> "Set the subvolume of the filesystem  which will be mounted\n"
> "as default."
> },
> + { do_get_default_subvol, 1, "subvolume get-default", "\n"
> + "Get the default subvolume of a filesystem."
> + },
> { do_fssync, 1,
> "filesystem sync", "\n"
> "Force a sync on the filesystem ."
> diff --git a/btrfs_cmds.c b/btrfs_cmds.c
> index 8031c58..11c56f6 100644
> --- a/btrfs_cmds.c
> +++ b/btrfs_cmds.c
> @@ -301,7 +301,7 @@ int do_subvol_list(int argc, char **argv)
> fprintf(stderr, "ERROR: can't access '%s'\n", subvol);
> return 12;
> }
> - ret = list_subvols(fd);
> + ret = list_subvols(fd, 0);
> if (ret)
> return 19;
> return 0;
> @@ -834,6 +834,35 @@ int do_set_default_subvol(int nargs, char **argv)
> return 0;
> }
>
> +int do_get_default_subvol(int nargs, char **argv)
> +{
> + int fd;
> + int ret;
> + ch

Re: Kernel Modules

[Andreas Philipp]

On 09.07.2011 18:19, cac...@quantum-sci.com wrote:
> Just compiled a custom kernel, but unable to mount a btrfs partition.  It 
> essentially says 'unrecognized filesystem'.  What could be missing?
>
> # File systems
> #
> CONFIG_EXT2_FS=y
> CONFIG_EXT2_FS_XATTR=y
> CONFIG_EXT2_FS_POSIX_ACL=y
> CONFIG_EXT2_FS_SECURITY=y
> # CONFIG_EXT2_FS_XIP is not set
> CONFIG_EXT3_FS=y
> CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
> CONFIG_EXT3_FS_XATTR=y
> CONFIG_EXT3_FS_POSIX_ACL=y
> CONFIG_EXT3_FS_SECURITY=y
> CONFIG_EXT4_FS=y
> CONFIG_EXT4_FS_XATTR=y
> # CONFIG_EXT4_FS_POSIX_ACL is not set
> # CONFIG_EXT4_FS_SECURITY is not set
> # CONFIG_EXT4_DEBUG is not set
> CONFIG_JBD=y
> # CONFIG_JBD_DEBUG is not set
> CONFIG_JBD2=y
> # CONFIG_JBD2_DEBUG is not set
> CONFIG_FS_MBCACHE=y
> # CONFIG_REISERFS_FS is not set
> CONFIG_JFS_FS=y
> # CONFIG_JFS_POSIX_ACL is not set
> # CONFIG_JFS_SECURITY is not set
> # CONFIG_JFS_DEBUG is not set
> # CONFIG_JFS_STATISTICS is not set
> # CONFIG_XFS_FS is not set
> # CONFIG_GFS2_FS is not set
> # CONFIG_OCFS2_FS is not set
> CONFIG_BTRFS_FS=y
> CONFIG_BTRFS_FS_POSIX_ACL=y
> # CONFIG_NILFS2_FS is not set
> CONFIG_FS_POSIX_ACL=y
> CONFIG_FILE_LOCKING=y
> CONFIG_FSNOTIFY=y
> CONFIG_DNOTIFY=y
> CONFIG_INOTIFY_USER=y
> # CONFIG_FANOTIFY is not set
> CONFIG_QUOTA=y
> CONFIG_QUOTA_NETLINK_INTERFACE=y
> CONFIG_PRINT_QUOTA_WARNING=y
> # CONFIG_QUOTA_DEBUG is not set
> CONFIG_QUOTA_TREE=m
> # CONFIG_QFMT_V1 is not set
> CONFIG_QFMT_V2=m
> CONFIG_QUOTACTL=y
> CONFIG_QUOTACTL_COMPAT=y
> CONFIG_AUTOFS4_FS=y
> CONFIG_FUSE_FS=y
> CONFIG_CUSE=y
> CONFIG_GENERIC_ACL=y
If your btrfs lives on two or more devices you will have to run 'btrfs
device scan' prior to mount or give all devices as arguments to mount.btrfs.

Andreas
--
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: How to get the default subvolume?

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 08.07.2011 11:58, Hugo Mills wrote:
> On Fri, Jul 08, 2011 at 05:58:02PM +0800, Yi Yang wrote:
>> I know I can set the default subvolume for a btrfs fs using
>>
>> sudo btrfs subvolume set-default 256 /btrfs/mnt
>>
>> But after that, how can get the default subvolume name? In my opinion,
>> btrfs-progs should provide "btrfs subvolume get-default /btrfs/mnm" to
get
>> the default subvolume id and name, I think it is very easy to do this in
>> btrfs-progs and btrfs kernel space.
>
> I don't think the current btrfs-progs will do it. As you pointed
> out though, it's pretty easy to write the code to get the information
> (I implemented it for btrfs-gui without any additional kernel code,
> for example). We just need someone to implement it. :)
>
> I'd do it myself, but there's about a dozen things higher up my
> priority list right now.
>
Well, I'd be happy to try it. If it's fine, I will try to follow the
implementation from btrfs-gui.
 
Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJOFtWBAAoJEJIcBJ3+Xkgi/loP/jBB2BnrDvdRrN+gxP5XcCr8
62ZgP2XxO/MrIH5Xc4iNfUlMF8Fnttjr8LvjpbP3Q2Vfb2ogPPf6ALpBxtCOhaHJ
yAFE4CvGon7f2sTGZO2EJxf4eSSoFUd19je+knPZOdyIDhc1lhXVp4LBeoPKySRe
GDBQtv1uqYx79hD24R5vU5uK1xMDTVE5HHCy8jZtoaVGU4YO87u7vFfNJKqAmS/W
tZbT3wkrod/HHo8sxS4ZKzPx1c0Ph/F3g/P8SWSHW5dmK/dSadRVe+Io09tyd6uu
GfGMMtEs6lVjHq/gn4ebDZwk3pFmCACnCxk6cE5imGWOIvftLMCFRZkFS41BVn7s
pAz+JEp7NaICKo3rbFlEZdvteBB0AaJTCeo2wAP0xD6aBEdT5MhxHZQCGi6PeRDn
2GTqw2gT+urTVa7Rr6O2PIQlC0mjFit6dVYcFzPIP/X+cXozDnuNeUmPD10VlEjN
PHIOJjNX3Zod8KknQc/NX0kn3TcHZptX0EWJhtnC0X4kHMxZOUrfnlIMTjCP23pX
TA4Zjc68fe5mDm75PnbT6h4QoLa5h3j8TWf8fYYFBC/FOcb4NFm4iJEA6AG7CS1l
MExGgd619NWUXHDpjjhTTzerBHF+1D5XPNc0lnb7WNkjzfBQD5JfkFzCp3lzTylU
dpaD5umGdM+1DlrD8NP/
=vM5/
-END PGP SIGNATURE-

--
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

free space defragmentation?

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Hi,
 
Since the defragmentation tool of btrfs-more or less-just copies the
file to the free space the file gets fragmented again (maybe even worse)
if the free space is fragmented. Thus I wanted to ask whether there is
some tool or idea for a free space defragmentation.
 
Thanks,
Andreas Philipp
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJOFMLXAAoJEJIcBJ3+XkgiK8cQAJqYE9VpDak555/5U1YHrrkH
eVJKn/N2nR0qO9pUh/XsMyStpntZ+yv/cVQ/i12mfG5ZZaCS6VBEZzNxooGQP6J2
jLgxYtfKUKaR8AHC0dzOkDN3OE78U1/grZV9SEE1wx05wXGMOipKcuVQZQSMOS1n
jP6FHYRVd22GGbMob9GxxNv+j/2ZSx5ThgYI1ZWbYRwD/XAEWHuMZuWElGTZrQaQ
7TZ4IzlQ4sMpZLbrp5m60EjdmW1G4mwREygSh8jmnZp0ndhWVzfbJorWJYDLLXIP
prlptDH0KJsAf5MBmxbG4fe7nKX+XagvbSaYEKaORS0di61NripELc3QgalPrfdN
r/NjirXuIhnmQMowV288ntsuOe/QHYn7RQbxOgLxxw0ageCZGay/Rwfcq9deI2pe
QoSbC2PBecGhGe7jd0jVpB3TmYil8uWs7VzzdxIhknadtYTotEP4WQYQyK4xQqU1
GDfYXnqLXXhFrJkSZ3EFEeRlfSVdw33VGEEdjnqoRoKkKTvXpwE+JhrdiJvSkOC2
7sIbocvU+KFWLjtXYqDZgOFndCx+6NQIRR/pP9NOYnSk4x8qqthi9h3EqiCq1jRo
JIttYHS3IEXv0P58VmCUwMaaXdNfWEqXr93j12WdvcoNDm/oCwdTB8u9Ckk9rhQQ
yuygcOK6z0XAAh/vlZFm
=jT/r
-END PGP SIGNATURE-

--
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

[PATCH] remove unused include "version.h"

[Andreas Philipp]

In the file btrfs-list.c version.h was included but not used. So just
drop it.

Signed-off-by: Andreas Philipp 
---
 btrfs-list.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/btrfs-list.c b/btrfs-list.c
index f804dfc..1495dae 100644
--- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -34,7 +34,6 @@
 #include "ctree.h"
 #include "transaction.h"
 #include "utils.h"
-#include "version.h"
 
 /* we store all the roots we find in an rbtree so that we can
  * search for them later.
-- 
1.7.3.4

--
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: [PATCH 2/3] add btrfs-list.o as a seperate target

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Please ignore this patch. I found a more elegant solution just right now.
Thanks,
Andreas

On 03.07.2011 20:43, Hugo Mills wrote:
> On Sat, Jul 02, 2011 at 12:44:37AM +0200, Andreas Philipp wrote:
>> By adding btrfs-list.o as a seperate target which depends additionally
> separate
>
>> on version we can fix the following build error when invoking 'make
>> btrfs'.
>>
>> btrfs-list.c:37:21: error: version.h: No such file or directory
>> make: *** [btrfs-list.o] Error 1
>>
>> Signed-off-by: Andreas Philipp 
>> ---
>> Makefile | 4 
>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/Makefile b/Makefile
>> index 3a1e308..c60f9af 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -27,6 +27,10 @@ else
>> check=ls
>> endif
>>
>> +btrfs-list.o: version
>> + $(check) btrfs-list.c
>> + $(CC) $(DEPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c btrfs-list.c
>> +
>> .c.o:
>> $(check) $<
>> $(CC) $(DEPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c $<
>
> This breaks the use of simple "make", as it just makes btrfs-list.o
> and nothing else. This new target should probably be put somewhere
> near the bottom of the file, not above the "all" target, where it
> becomes the default:
>
> hrm@ruthven:btrfs-progs-unstable $ make
> bash version.sh
> ls btrfs-list.c
> btrfs-list.c
> gcc -Wp,-MMD,./.btrfs-list.o.d,-MT,btrfs-list.o -Wall -D_FILE_OFFSET_BITS=64 
> -D_FORTIFY_SOURCE=2 -g -Werror -Os -c btrfs-list.c
> hrm@ruthven:btrfs-progs-unstable $
>
> Hugo.
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJOEL88AAoJEJIcBJ3+XkgiAZ4QAIz+zHogJAs6Te/sxkttiItl
uudHpZJFiPDsD9jOrynewG9w3leKbde8pr9niB8fcDWwtdRp+z3k86CTNegVmkuv
75MkH5YEOjg8dVawaamjFLC0ENJMe/u3f3Ry982Ts7HDctCiABEfF4+XZ5dkrClk
igqNljcFrPS7s/X3lo3C9WNyJuPtdV1Woyy5a0u8d7NTsuLEDTq4jnup4zd6ObTd
MpQNNLb28rv2l9X9tRX2bRlneoSVtKdhb4tEAWG3miVyB3wDR+/9EJiGeYZlG52v
tXwbuTa8lngwJuVZsjhm+nzgJHVW3I6CXj13L4yxdQX8IKRQ+PrfR6HhEyO84Jim
IKdtKEsvI5sHucAiG26YuOSp6vnkiwebDsOmxnXsfr9EVcKlPQC7yYB1Akh7jMBe
BIy38RaB87nbI5m7ra4e+IGkl2stjZ7GdspjQg97wZI1WRdAu1NSsG6EbO05GZ3v
v/p4llrXH0Dl1ylygz9Prwkz9w5GVOpo88Ck0XOFtf8UrQJEMEMs8BwLu65prkmY
7L1srODGe+hpYLYEjBNL3iwACcLX5Yd80nHJBb+rdwLN8N3LXve6SxPw/pLgdty2
Su5o0AU39csp427OM1fExDbqphfsFhkK3SMOOGXS52Bed+iYXAzcJFGQ7c53l3vB
3qQ4EWe7LeX3gY6yd/EO
=JgSk
-END PGP SIGNATURE-

--
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: btrfs-progs: integration branch updated

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 30.06.2011 23:19, Hugo Mills wrote:
> After a reorganisation of patches, and sending a bunch of them to
> Chris, I've also updated the integration branch to match that. It's
> available from:
>
> http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ integration-20110630
>
> The shortlog of 17 patches in this branch beyond the ones I've sent
> to Chris is below.
>
When trying to build 'dir-test' I encountered a lot of build errors; see below.

Cheers,
Andreas

ls ctree.c
ctree.c
gcc -Wp,-MMD,./.ctree.o.d,-MT,ctree.o -Wall -D_FILE_OFFSET_BITS=64 
-D_FORTIFY_SOURCE=2 -g -Werror -Os -c ctree.c
ls disk-io.c
disk-io.c
gcc -Wp,-MMD,./.disk-io.o.d,-MT,disk-io.o -Wall -D_FILE_OFFSET_BITS=64 
-D_FORTIFY_SOURCE=2 -g -Werror -Os -c disk-io.c
ls radix-tree.c
radix-tree.c
gcc -Wp,-MMD,./.radix-tree.o.d,-MT,radix-tree.o -Wall -D_FILE_OFFSET_BITS=64 
-D_FORTIFY_SOURCE=2 -g -Werror -Os -c radix-tree.c
ls extent-tree.c
extent-tree.c
gcc -Wp,-MMD,./.extent-tree.o.d,-MT,extent-tree.o -Wall -D_FILE_OFFSET_BITS=64 
-D_FORTIFY_SOURCE=2 -g -Werror -Os -c extent-tree.c
ls print-tree.c
print-tree.c
gcc -Wp,-MMD,./.print-tree.o.d,-MT,print-tree.o -Wall -D_FILE_OFFSET_BITS=64 
-D_FORTIFY_SOURCE=2 -g -Werror -Os -c print-tree.c
ls root-tree.c
root-tree.c
gcc -Wp,-MMD,./.root-tree.o.d,-MT,root-tree.o -Wall -D_FILE_OFFSET_BITS=64 
-D_FORTIFY_SOURCE=2 -g -Werror -Os -c root-tree.c
ls dir-item.c
dir-item.c
gcc -Wp,-MMD,./.dir-item.o.d,-MT,dir-item.o -Wall -D_FILE_OFFSET_BITS=64 
-D_FORTIFY_SOURCE=2 -g -Werror -Os -c dir-item.c
ls file-item.c
file-item.c
gcc -Wp,-MMD,./.file-item.o.d,-MT,file-item.o -Wall -D_FILE_OFFSET_BITS=64 
-D_FORTIFY_SOURCE=2 -g -Werror -Os -c file-item.c
ls inode-item.c
inode-item.c
gcc -Wp,-MMD,./.inode-item.o.d,-MT,inode-item.o -Wall -D_FILE_OFFSET_BITS=64 
-D_FORTIFY_SOURCE=2 -g -Werror -Os -c inode-item.c
ls inode-map.c
inode-map.c
gcc -Wp,-MMD,./.inode-map.o.d,-MT,inode-map.o -Wall -D_FILE_OFFSET_BITS=64 
-D_FORTIFY_SOURCE=2 -g -Werror -Os -c inode-map.c
ls crc32c.c
crc32c.c
gcc -Wp,-MMD,./.crc32c.o.d,-MT,crc32c.o -Wall -D_FILE_OFFSET_BITS=64 
-D_FORTIFY_SOURCE=2 -g -Werror -Os -c crc32c.c
ls rbtree.c
rbtree.c
gcc -Wp,-MMD,./.rbtree.o.d,-MT,rbtree.o -Wall -D_FILE_OFFSET_BITS=64 
-D_FORTIFY_SOURCE=2 -g -Werror -Os -c rbtree.c
ls extent-cache.c
extent-cache.c
gcc -Wp,-MMD,./.extent-cache.o.d,-MT,extent-cache.o -Wall 
-D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -g -Werror -Os -c extent-cache.c
ls extent_io.c
extent_io.c
gcc -Wp,-MMD,./.extent_io.o.d,-MT,extent_io.o -Wall -D_FILE_OFFSET_BITS=64 
-D_FORTIFY_SOURCE=2 -g -Werror -Os -c extent_io.c
ls volumes.c
volumes.c
gcc -Wp,-MMD,./.volumes.o.d,-MT,volumes.o -Wall -D_FILE_OFFSET_BITS=64 
-D_FORTIFY_SOURCE=2 -g -Werror -Os -c volumes.c
ls utils.c
utils.c
gcc -Wp,-MMD,./.utils.o.d,-MT,utils.o -Wall -D_FILE_OFFSET_BITS=64 
-D_FORTIFY_SOURCE=2 -g -Werror -Os -c utils.c
bash version.sh
ls btrfs-list.c
btrfs-list.c
gcc -Wp,-MMD,./.btrfs-list.o.d,-MT,btrfs-list.o -Wall -D_FILE_OFFSET_BITS=64 
-D_FORTIFY_SOURCE=2 -g -Werror -Os -c btrfs-list.c
ls btrfslabel.c
btrfslabel.c
gcc -Wp,-MMD,./.btrfslabel.o.d,-MT,btrfslabel.o -Wall -D_FILE_OFFSET_BITS=64 
-D_FORTIFY_SOURCE=2 -g -Werror -Os -c btrfslabel.c
ls dir-test.c
dir-test.c
gcc -Wp,-MMD,./.dir-test.o.d,-MT,dir-test.o -Wall -D_FILE_OFFSET_BITS=64 
-D_FORTIFY_SOURCE=2 -g -Werror -Os -c dir-test.c
cc1: warnings being treated as errors
dir-test.c: In function ?initial_inode_init?:
dir-test.c:66: error: passing argument 1 of ?btrfs_set_inode_generation? from 
incompatible pointer type
ctree.h:1064: note: expected ?struct extent_buffer *? but argument is of type 
?struct btrfs_inode_item *?
dir-test.c:66: error: passing argument 2 of ?btrfs_set_inode_generation? makes 
pointer from integer without a cast
ctree.h:1064: note: expected ?struct btrfs_inode_item *? but argument is of 
type ?u64?
dir-test.c:66: error: too few arguments to function ?btrfs_set_inode_generation?
dir-test.c:67: error: passing argument 1 of ?btrfs_set_inode_mode? from 
incompatible pointer type
ctree.h:1073: note: expected ?struct extent_buffer *? but argument is of type 
?struct btrfs_inode_item *?
dir-test.c:67: error: passing argument 2 of ?btrfs_set_inode_mode? makes 
pointer from integer without a cast
ctree.h:1073: note: expected ?struct btrfs_inode_item *? but argument is of 
type ?int?
dir-test.c:67: error: too few arguments to function ?btrfs_set_inode_mode?
dir-test.c: In function ?ins_one?:
dir-test.c:89: error: ?struct btrfs_key? has no member named ?flags?
dir-test.c:98: error: too few arguments to function ?btrfs_insert_dir_item?
dir-test.c:118: error: assignment makes integer from pointer without a cast
dir-test.c:128: error: ?struct extent_buffer? has no member named ?leaf?
dir-test.c:128: error: ?struct extent_buffer? has no member named ?leaf?
dir-test.c:131: error: passing argument 1 of ?btrfs_dir_name_len? from 
incompatible pointer type
ctree.h:1346: note: expected ?struct extent_bu

Re: [PATCH] Re: [btrfs-progs integration] incorrect argument checking for "btrfs sub snap -r"

[Andreas Philipp]

On 01.07.2011 10:26, Stephane Chazelas wrote:
> 2011-06-30 22:55:15 +0200, Andreas Philipp:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>  
>> On 30.06.2011 14:34, Stephane Chazelas wrote:
>>> Looks like this was missing in integration-20110626 for the
>>> readonly snapshot patch:
>>>
>>> diff --git a/btrfs.c b/btrfs.c
>>> index e117172..be6ece5 100644
>>> --- a/btrfs.c
>>> +++ b/btrfs.c
>>> @@ -49,7 +49,7 @@ static struct Command commands[] = {
>>> /*
>>> avoid short commands different for the case only
>>> */
>>> - { do_clone, 2,
>>> + { do_clone, -1,
>>> "subvolume snapshot", "[-r]  [/]\n"
>>> "Create a writable/readonly snapshot of the subvolume  with\n"
>>> "the name  in the  directory.",
>>>
>>> Without that, "btrfs sub snap -r x y" would fail as it's not *2*
>>> arguments.
>> Unfortunately, this is not correct either. "-1" means that the minimum
>> number of arguments is 1 and since we need at least  and
>>  this is 2. So the correct version should be -2.
> [...]
>
> Sorry, without looking closely at the source, I assumed -1 meant
> defer the checking to the subcommand handler.
>
> do_clone will indeed return an error if the number of arguments
> is less than expected (so with -2, you'll get a different error
> message if you do "btrfs sub snap -r foo" or "btrfs sub snap
> foo") , but will not if it's more than expected by the way.
>
> So the patch should probably be:
>
> diff --git a/btrfs.c b/btrfs.c
> index e117172..b50c58a 100644
> --- a/btrfs.c
> +++ b/btrfs.c
> @@ -49,7 +49,7 @@ static struct Command commands[] = {
>   /*
>   avoid short commands different for the case only
>   */
> - { do_clone, 2,
> + { do_clone, -2,
> "subvolume snapshot", "[-r]  [/]\n"
>   "Create a writable/readonly snapshot of the subvolume  
> with\n"
>   "the name  in the  directory.",
> diff --git a/btrfs_cmds.c b/btrfs_cmds.c
> index 1d18c59..3415afc 100644
> --- a/btrfs_cmds.c
> +++ b/btrfs_cmds.c
> @@ -355,7 +355,7 @@ int do_clone(int argc, char **argv)
>   return 1;
>   }
>   }
> - if (argc - optind < 2) {
> + if (argc - optind != 2) {
>   fprintf(stderr, "Invalid arguments for subvolume snapshot\n");
>   free(argv);
>   return 1;
>
Thanks for having another look at this. You are perfectly right. Should
we patch my patch or should I rework a corrected version? What do you
think Hugo?

Cheers,
Andreas
--
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

[PATCH v2] print parent ID in btrfs suvolume list

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

There was some discussion on "where" subvolumes live in. Why do we not
simply print the parent ID for each subvolume in btrfs subvolume list?
This patch adds this functionality when called with parameter "-p".

Signed-off-by: Andreas Philipp 
- ---
V1->V2: do not change the default behavior but rather add the switch -p.

 btrfs-list.c |   24 ++--
 btrfs.c  |6 --
 btrfs_cmds.c |   17 +++--
 btrfs_cmds.h |2 +-
 4 files changed, 38 insertions(+), 11 deletions(-)

diff --git a/btrfs-list.c b/btrfs-list.c
index f804dfc..be20c91 100644
- --- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -200,9 +200,10 @@ static int add_root(struct root_lookup *root_lookup,
  * This can't be called until all the root_info->path fields are filled
  * in by lookup_ino_path
  */
- -static int resolve_root(struct root_lookup *rl, struct root_info *ri)
+static int resolve_root(struct root_lookup *rl, struct root_info *ri, int 
print_parent)
 {
u64 top_id;
+   u64 parent_id = 0;
char *full_path = NULL;
int len = 0;
struct root_info *found;
@@ -233,6 +234,11 @@ static int resolve_root(struct root_lookup *rl, struct 
root_info *ri)
}
 
next = found->ref_tree;
+   /* record the first parent */
+   if ( parent_id == 0 ) {
+   parent_id = next;
+   }
+
/* if the ref_tree refers to ourselves, we're at the top */
if (next == found->root_id) {
top_id = next;
@@ -249,9 +255,15 @@ static int resolve_root(struct root_lookup *rl, struct 
root_info *ri)
break;
}
}
- - printf("ID %llu top level %llu path %s\n",
- -(unsigned long long)ri->root_id, (unsigned long long)top_id,
- -full_path);
+   if (print_parent) {
+   printf("ID %llu parent %llu top level %llu path %s\n",
+  (unsigned long long)ri->root_id, (unsigned long 
long)parent_id, (unsigned long long)top_id,
+   full_path);
+   } else {
+   printf("ID %llu top level %llu path %s\n",
+  (unsigned long long)ri->root_id, (unsigned long 
long)top_id,
+   full_path);
+   }
free(full_path);
return 0;
 }
@@ -549,7 +561,7 @@ build:
return full;
 }
 
- -int list_subvols(int fd)
+int list_subvols(int fd, int print_parent)
 {
struct root_lookup root_lookup;
struct rb_node *n;
@@ -666,7 +678,7 @@ int list_subvols(int fd)
while (n) {
struct root_info *entry;
entry = rb_entry(n, struct root_info, rb_node);
- - resolve_root(&root_lookup, entry);
+   resolve_root(&root_lookup, entry, print_parent);
n = rb_prev(n);
}
 
diff --git a/btrfs.c b/btrfs.c
index 87cc680..d09823a 100644
- --- a/btrfs.c
+++ b/btrfs.c
@@ -66,9 +66,11 @@ static struct Command commands[] = {
"not passed).",
  NULL
},
- - { do_subvol_list, 1, "subvolume list", "\n"
+   { do_subvol_list, -1, "subvolume list", "[-p] \n"
"List the snapshot/subvolume of a filesystem.",
- -   NULL
+   "[-p] \n"
+   "List the snapshot/subvolume of a filesystem.\n"
+   "-pprint parent ID"
},
{ do_set_default_subvol, 2,
  "subvolume set-default", " \n"
diff --git a/btrfs_cmds.c b/btrfs_cmds.c
index 062e7d7..9e0c9bc 100644
- --- a/btrfs_cmds.c
+++ b/btrfs_cmds.c
@@ -303,9 +303,22 @@ int do_subvol_list(int argc, char **argv)
 {
int fd;
int ret;
+   int print_parent = 0;
char *subvol;
+int optind = 1;
 
- - subvol = argv[1];
+   while(1) {
+   int c = getopt(argc, argv, "p");
+   if (c < 0) break;
+   switch(c) {
+   case 'p':
+   print_parent = 1;
+   optind++;
+   break;
+   }
+   }
+
+   subvol = argv[optind];
 
ret = test_issubvolume(subvol);
if (ret < 0) {
@@ -322,7 +335,7 @@ int do_subvol_list(int argc, char **argv)
fprintf(stderr, "ERROR: can't access '%s'\n", subvol);
return 12;
}
- - ret = list_subvols(fd);
+   ret = list_subvols(fd, print_parent);
if (ret)
return 19;
return 0;
diff --git a/btrfs_cmds.h b/btrfs_cmds.h
index 61456fa..83faa5b 100644
- --- a/btrfs_cmds.h
+++ b/btrfs_cmds.h
@@ -34,7 +34,7 @@ int do_scan(int nargs, char **argv);
 int 

Re: [PATCH v6 2/8] Add --monitor option to btrfs balance progress.

[Andreas Philipp]

On 01.05.2011 17:47, Hugo Mills wrote:
> For the impatient, this patch introduces the pot-watching --monitor
> option, which checks the balance progress at regular intervals, and
> updates a single status line with the current progress and an
> estimated completion time.
>
> Signed-off-by: Hugo Mills 
> ---
>  btrfs.c|4 +-
>  btrfs_cmds.c   |  109 ++-
>  ioctl.h|2 +-
>  man/btrfs.8.in |7 ++--
>  4 files changed, 106 insertions(+), 16 deletions(-)
>
> diff --git a/btrfs.c b/btrfs.c
> index 3a24019..0b6186c 100644
> --- a/btrfs.c
> +++ b/btrfs.c
> @@ -99,8 +99,8 @@ static struct Command commands[] = {
> "balance start", "\n"
>   "Synonym for \"btrfs filesystem balance\"."
>   },
> - { do_balance_progress, 1,
> -   "balance progress", "\n"
> + { do_balance_progress, -1,
> +   "balance progress", "[-m|--monitor] \n"
>   "Show progress of the balance operation running on ."
>   },
>   { do_scan,
> diff --git a/btrfs_cmds.c b/btrfs_cmds.c
> index 00dda0a..ad2300d 100644
> --- a/btrfs_cmds.c
> +++ b/btrfs_cmds.c
> @@ -797,22 +797,108 @@ int get_balance_progress(char *path, struct 
> btrfs_ioctl_balance_progress *bal)
>   return err;
>  }
>  
> +const struct option progress_options[] = {
> + { "monitor", 0, NULL, 'm' },
> + { NULL, 0, NULL, 0 }
> +};
> +
>  int do_balance_progress(int argc, char **argv)
>  {
>   char *path;
>   int ret = 0;
>   int err = 0;
>   struct btrfs_ioctl_balance_progress bal;
> + __u64 last_completed = -1;
> + __u64 initial_completed = -1;
> + struct timeval now;
> + struct timeval started;
> + int monitor = 0;
> +
> + optind = 1;
> + while(1) {
> + int c = getopt_long(argc, argv, "m", progress_options, NULL);
> + if (c < 0)
> + break;
> + switch(c) {
> + case 'm':
> + monitor = 1;
> + break;
> + default:
> + fprintf(stderr, "Invalid arguments for balance 
> progress\n");
> + free(argv);
> + return 1;
> + }
> + }
> +
> + if(optind >= argc) {
> + fprintf(stderr, "No filesystem path given for progress\n");
> + return 1;
> + }
> +
> + path = argv[optind];
> + do {
> + int prs = 0;
>  
> - path = argv[1];
> + ret = get_balance_progress(path, &bal);
> + if (ret)
> + break;
>  
> - ret = get_balance_progress(path, &bal);
> - if (!ret)
> - printf("\r%u/%u block groups moved, "
> -"%0.2f%% complete.\n",
> -bal.completed,
> -bal.expected,
> -(float)bal.completed/bal.expected*100.0);
> + if (last_completed != bal.completed) {
> + printf("\r%u/%u block groups moved, "
> +"%0.2f%% complete.",
> +bal.completed,
> +bal.expected,
> +(float)bal.completed/bal.expected*100.0);
> + }
> +
> + if (initial_completed != -1
> + && initial_completed != bal.completed) {
> + ret = gettimeofday(&now, NULL);
> + if (ret) {
> + fprintf(stderr, "Can't read current time\n");
> + return 22;
> + }
> + /* Seconds per block */
> + float rate = (float)(now.tv_sec - started.tv_sec)
> + / (bal.completed - initial_completed);
> + int secs_remaining = rate
> + * (bal.expected - bal.completed);
> + printf(" Time remaining");
> + if (secs_remaining >= 60*60*24) {
> + printf(" %dd", secs_remaining / (60*60*24));
> + secs_remaining %= 60*60*24;
> + prs = 1;
> + }
> + if (prs || secs_remaining >= 60*60) {
> + printf(" %dh", secs_remaining / (60*60));
> + secs_remaining %= 60*60;
> + prs = 1;
> + }
> + if (prs || secs_remaining > 60) {
> + printf(" %dm", secs_remaining / 60);
> + secs_remaining %= 60;
> + }
> + printf(" %ds\x1b[K", secs_remaining);
> + }
> +
> + if (last_completed != -1 && last_completed != bal.completed) {
> + initial_completed = bal.completed;
> + ret = gettimeofday(&start

Re: [PATCH v6 2/8] Add --monitor option to btrfs balance progress.

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 01.05.2011 17:47, Hugo Mills wrote:
> For the impatient, this patch introduces the pot-watching
> --monitor option, which checks the balance progress at regular
> intervals, and updates a single status line with the current
> progress and an estimated completion time.
>
> Signed-off-by: Hugo Mills  --- btrfs.c |
> 4 +- btrfs_cmds.c | 109
> ++- ioctl.h
> | 2 +- man/btrfs.8.in | 7 ++-- 4 files changed, 106
> insertions(+), 16 deletions(-)
>
> diff --git a/btrfs.c b/btrfs.c index 3a24019..0b6186c 100644 ---
> a/btrfs.c +++ b/btrfs.c @@ -99,8 +99,8 @@ static struct Command
> commands[] = { "balance start", "\n" "Synonym for \"btrfs
> filesystem balance\"." }, - { do_balance_progress, 1, - "balance
> progress", "\n" + { do_balance_progress, -1, + "balance
> progress", "[-m|--monitor] \n" "Show progress of the balance
> operation running on ." }, { do_scan, diff --git
> a/btrfs_cmds.c b/btrfs_cmds.c index 00dda0a..ad2300d 100644 ---
> a/btrfs_cmds.c +++ b/btrfs_cmds.c @@ -797,22 +797,108 @@ int
> get_balance_progress(char *path, struct
> btrfs_ioctl_balance_progress *bal) return err; }
>
> +const struct option progress_options[] = { + { "monitor", 0, NULL,
> 'm' }, + { NULL, 0, NULL, 0 } +}; + int do_balance_progress(int
> argc, char **argv) { char *path; int ret = 0; int err = 0; struct
> btrfs_ioctl_balance_progress bal; + __u64 last_completed = -1; +
> __u64 initial_completed = -1; + struct timeval now; + struct
> timeval started; + int monitor = 0; + + optind = 1; + while(1) { +
> int c = getopt_long(argc, argv, "m", progress_options, NULL); + if
> (c < 0) + break; + switch(c) { + case 'm': + monitor = 1; +
> break; + default: + fprintf(stderr, "Invalid arguments for
> balance progress\n"); + free(argv); + return 1; + } + } + +
> if(optind >= argc) { + fprintf(stderr, "No filesystem path given
> for progress\n"); + return 1; + } + + path = argv[optind]; + do {
> + int prs = 0;
>
> - path = argv[1]; + ret = get_balance_progress(path, &bal); + if
> (ret) + break;
>
> - ret = get_balance_progress(path, &bal); - if (!ret) -
> printf("\r%u/%u block groups moved, " - "%0.2f%%
> complete.\n", - bal.completed, - bal.expected, -
> (float)bal.completed/bal.expected*100.0); + if (last_completed !=
> bal.completed) { + printf("\r%u/%u block groups moved, " +
> "%0.2f%% complete.", + bal.completed, +
> bal.expected, + (float)bal.completed/bal.expected*100.0);
> + } + + if (initial_completed != -1 + && initial_completed
> != bal.completed) { + ret = gettimeofday(&now, NULL); + if
> (ret) { + fprintf(stderr, "Can't read current time\n"); +
> return 22; + } + /* Seconds per block */ + float rate =
> (float)(now.tv_sec - started.tv_sec) + / (bal.completed -
> initial_completed); + int secs_remaining = rate + *
> (bal.expected - bal.completed); + printf(" Time remaining"); +
> if (secs_remaining >= 60*60*24) { + printf(" %dd",
> secs_remaining / (60*60*24)); + secs_remaining %= 60*60*24; +
> prs = 1; + } + if (prs || secs_remaining >= 60*60) { +
> printf(" %dh", secs_remaining / (60*60)); + secs_remaining %=
> 60*60; + prs = 1; + } + if (prs || secs_remaining > 60) { +
> printf(" %dm", secs_remaining / 60); + secs_remaining %= 60; +
> } + printf(" %ds\x1b[K", secs_remaining); + } + + if
> (last_completed != -1 && last_completed != bal.completed) { +
> initial_completed = bal.completed; + ret = gettimeofday(&started,
> NULL); + if (ret) { + fprintf(stderr, "Can't read current
> time\n"); + return 22; + } + } + + last_completed =
> bal.completed; + + if (monitor) { + fflush(stdout); +
> sleep(1); + } else { + printf("\n"); + } + } while(monitor);
>
> switch(ret) { case 0: @@ -821,10 +907,13 @@ int
> do_balance_progress(int argc, char **argv) fprintf(stderr, "ERROR:
> can't access '%s'\n", path); return 13; case EINVAL: -
> fprintf(stderr, + if (!monitor) { + fprintf(stderr, "No
> balance operation running on '%s'.\n", path); - return 20; +
> return 20; + } + break; default: fprintf(stderr, "ERROR: ioctl
> returned error %d.", err);
The output of fprintf should end with a newline.
Cheers,
Andreas
> return 21; diff --git a/ioctl.h b/ioctl.h index f07d3a2..3eeaa33
> 100644 --- a/ioctl.h +++ b/ioctl.h @@ -174,6 +174,6 @@ struct
> btrfs_ioctl_balance_progress { #define BTRFS_IOC_DEFAULT_SUBVOL
> _IOW(BTRFS_IOCTL_MAGIC, 19, u64) #define BTRFS_IOC_SPACE_INFO
> _IOWR(BTRFS_IOCTL_MAGIC, 20, \ struct btrfs_ioctl_space_args)
> -#define BTRFS_IOC_BALANCE_PROGRESS _IOR(BTRFS_IOCTL_MAGIC, 25, \
> +#define BTRFS_IOC_BALANCE_PROGRESS _IOR(BTRFS_IOCTL_MAGIC, 27, \
> struct btrfs_ioctl_balance_progress) #endif diff --git
> a/man/btrfs.8.in b/man/btrfs.8.in index 7b66fb7..5fcad89 100644 ---
> a/man/btrfs.8.in +++ b/man/btrfs.8.in @@ -27,7 +27,7 @@ btrfs \-
> control a btrfs filesystem .PP \fBbtrfs\fP \fBbalance start\fP\fI
>  \fP .PP -\fBbtrfs\fP \fBbalance progress\fP\fI \fP
> +\fBbtrfs\fP \fBbalance progress\fP [\fB-m\fP|\fB--monitor\fP]
> \f

Re: btrfs-progs: integration branch updated

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 30.06.2011 23:19, Hugo Mills wrote:
> After a reorganisation of patches, and sending a bunch of them to
> Chris, I've also updated the integration branch to match that.
> It's available from:
>
> http://git.darksatanic.net/repo/btrfs-progs-unstable.git/
> integration-20110630
>
> The shortlog of 17 patches in this branch beyond the ones I've
> sent to Chris is below.
>
> Hugo.
>
>
> Andreas Philipp (1): print parent ID in btrfs subvolume list
>
> Goffredo Baroncelli (1): Scan the devices listed in
> /proc/partitions
>
> Hugo Mills (8): Balance progress monitoring. Add --monitor option
> to btrfs balance progress. User-space tool for cancelling balance
> operations. Run userspace tool in background for balances. Initial
> implementation of userspace interface for filtered balancing.
> Balance filter by device ID Balance filter for virtual address
> range Interface for device range balance filter
>
> Jan Schmidt (5): commands added scrub ioctls added
> check_mounted_where scrub userland implementation scrub added to
> manpage
>
> WuBo (1): Btrfs-progs: Add chunk tree recover tool
>
> Zhong, Xin (1): btrfs-progs: Improvement for making btrfs image
> from source directory.

When issuing 'make all' in this branch I get the following error:
make: *** No rule to make target `btrfs-recover-chunk.o', needed by
`btrfs-recover-chunk'.  Stop.
When trying to figure out what is going wrong I did not find a file
called btrfs-recover-chunk.c. Might it be missing?

Thanks,
Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJODO73AAoJEJIcBJ3+XkgirYkP/RBdxbKj5yluUVmlRaCGmvCy
VZMmL3M/+VsmdZykhtUyz17kE3qzFUCAswZK1axpka/YNKhKeNWKVdrUUOXvJjJs
5pkWN/WhtFpmRi/YJzT+vsvhPNSEcevQMEYzN46uTK7kjR/kebrCPhC6AHBPLBQl
8sMT091IvpU+dKBCH9bCEG8pVL5InUNoQ8TiiegL4RkdQlYfKqbUvv6Jb/P/Qx6w
60unoJpxdpX4f4yRuTX9F2vhloJ1t8qTa2eIWF/SCFQpx/9Zy4pY/XmfjfFWWMQa
0zkZ0+G9+e7cJXVAtlQVdpQhQnlSuhgM23YGerMc0k39HaGeWEEpflAkd1sP4f7w
RJWrS0og0oFKMEjK8Vs/ZJCzYGN5tapb74CXXJxO6dTXLm0mV7siJrLKBB39yIjZ
IOw09qXX3CrSETpbohX3BaFP9CxyEPwOEYIxV+0kV5Eo27Jf36cctmPD1WDlzw+/
V1MvDCEeuIiXoUBa/3gnP/PKGErsRXP4GUrf5SXkKdzU7fl1L53yvd+ogbX01H/7
SW3PONw/peUoH2Lz/TX7Sr+ifhhmoJ6RRhdytZ2yaKpq4NOWqTFKQQtGO7SLAeqL
KIK42N2yHJraIk4r5I0ULoRrK8miinaAVBGRAw9nL1pmISN0EjqhEsZB7T/HjrU7
Hsd4HWo9gqabu90eZgn6
=9fXs
-END PGP SIGNATURE-

--
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: btrfs-progs: integration branch updated

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 30.06.2011 23:19, Hugo Mills wrote:
> After a reorganisation of patches, and sending a bunch of them to
> Chris, I've also updated the integration branch to match that.
> It's available from:
>
> http://git.darksatanic.net/repo/btrfs-progs-unstable.git/
> integration-20110630
>
> The shortlog of 17 patches in this branch beyond the ones I've
> sent to Chris is below.
>
> Hugo.
>
>
> Andreas Philipp (1): print parent ID in btrfs subvolume list
This is still the first version of my patch, which changes the default
output from btrfs subvolume list and breaks xfstests/254. Please use v2.

Thanks,
Andreas
>
> Goffredo Baroncelli (1): Scan the devices listed in
> /proc/partitions
>
> Hugo Mills (8): Balance progress monitoring. Add --monitor option
> to btrfs balance progress. User-space tool for cancelling balance
> operations. Run userspace tool in background for balances. Initial
> implementation of userspace interface for filtered balancing.
> Balance filter by device ID Balance filter for virtual address
> range Interface for device range balance filter
>
> Jan Schmidt (5): commands added scrub ioctls added
> check_mounted_where scrub userland implementation scrub added to
> manpage
>
> WuBo (1): Btrfs-progs: Add chunk tree recover tool
>
> Zhong, Xin (1): btrfs-progs: Improvement for making btrfs image
> from source directory.
>
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJODOnmAAoJEJIcBJ3+XkgiWSEP/3II1hXQhkp8r/ifViY1gbU0
0hREU65LlzNuGgkXj717wodnc87dCeDK3sxhj6EC8ND051XqfbrVMGlgG8Mzbtam
BGdZLO4Fabya0B3lu8I+vIyc63VvWHU6gMhbrshMPAjF9ZJEB3z4qC9xVK1869mX
ZPdqzz4Zm6nVq+KzcgDC7eIKFMX4cYZWVC22+rCTXvj5KLkb2wLldpYMzuGNUSYJ
evAviUQnkSLsu4393wwORa/9liOXgPeHdsMXIh3RFO33+MsRuLMZC+nl07/xA1w6
QQ7uSDpIaeuX2VddFIUbPLX69Uij/jsOnsFnlWgnkMMiFtdwSK2VkSBdAi91HjVL
BeTWJM8dzNZoNh6fvkc+40fFPxRk0T2FDMMitwLN6MU3aYUDJPsoOGX8sZ0SPhZg
w1nhhxLsbusWLfVoAi2KUa1auEOopVsACBEeSMxmy/c5vc47wwgf9F6TfzsszyYt
mAieWUWXVxktlw+hZB4Pnp0GOg7qXdyfkm3s8WMtPLJNiXj+LCyjVzPU2C6jqL9P
cU/0OvM64J5NGPqAwYo4+0tPhKm1TvjTlC7jYyHewvJ4hzW8HRO12UqwCASfmMZi
qCr0/EyYiCkcbzsRkRR6Ea47ipMofFaynkI0HYLcwvN5A366Zz5MFztEQjOPrbqP
J9iOP8BnjrTiJpAv3IYc
=uO19
-END PGP SIGNATURE-

--
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: [PATCH] [btrfs-progs integration] incorrect argument checking for "btrfs sub snap -r"

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 30.06.2011 14:34, Stephane Chazelas wrote:
> Looks like this was missing in integration-20110626 for the
> readonly snapshot patch:
>
> diff --git a/btrfs.c b/btrfs.c
> index e117172..be6ece5 100644
> --- a/btrfs.c
> +++ b/btrfs.c
> @@ -49,7 +49,7 @@ static struct Command commands[] = {
> /*
> avoid short commands different for the case only
> */
> - { do_clone, 2,
> + { do_clone, -1,
> "subvolume snapshot", "[-r]  [/]\n"
> "Create a writable/readonly snapshot of the subvolume  with\n"
> "the name  in the  directory.",
>
> Without that, "btrfs sub snap -r x y" would fail as it's not *2*
> arguments.
Unfortunately, this is not correct either. "-1" means that the minimum
number of arguments is 1 and since we need at least  and
 this is 2. So the correct version should be -2.

Thanks,
Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJODOKyAAoJEJIcBJ3+XkgiEzEP/1vXuvIqPvWQ6Yg3KGW31vZB
80BZRUIKJQel2VqZ8NN4mNJoXPsQ3r21gTv9aZQwHHnCRszBCDqo5uhJUIKfVsWX
WIOkQo6uJLUeO5tCwuIGBDwzy8WBgFyCNhUT06GVNJxNP2WZddsp3Wo540Mmmoof
en3+4SPC5godW2+t80811le+bfQpZ1N+Q2MXLTx0ilvt3y2cCjoV26yIhRj1mzOn
QBKRZCwvMafmE9jBdZLIx4h+W3agT3EWQj9F7c4ZsJFsrc5SJWtjMNZrWg8aRtYR
YFcHwuAH4IzVHxB0a84tiCtH+N+fnmQpXUWUZGjJLODgmJnJ+wq/vi1ek2J8Dw+c
pF3E+U6oy/bX/sQ7Ef/Zxs3qlp88hgLypd9Y2/Lk7i0XmKNYxpg9KisMiAS+Ensa
ucb0lNxB1rCSEtN48JfWJ55aA0Yh4B1WompXuRseekcVKFuOW/OqBkE73Q0YBSQo
FogqVGvrdmfgAeC8Uft83oo1zXXNYoxIpP5PjPgmpgwBQihZDHfVqbagFhKnRsRq
bsXyzl2C7SkgVUxtuD3/Co3uyFm/So9MsgJmkcDDGo4APhUGxSOxGqhWo49C/1CZ
xfUSC1+rYnzTwK+5vhjbJjjXTdjaRGprcEH0803+cVikPdOSYfKsztrf+9OGSAp7
J+vEuVEESjhEcn2ySfSx
=bSbf
-END PGP SIGNATURE-

--
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: subvolumes missing from "btrfs subvolume list" output

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 30.06.2011 12:43, Stephane Chazelas wrote:
> 2011-06-30 11:18:42 +0200, Andreas Philipp: [...]
>>>> After that, I posted a patch to fix btrfs-progs, which Chris
>>>> aggreed on:
>>>>
>>>> http://marc.info/?l=linux-btrfs&m=129238454714319&w=2
>>> [...]
>>>
>>> Great. Thanks a lot
>>>
>>> It fixes my problem indeed.
>>>
>>> Which brings me to my next question: where to find the latest
>>> btrfs-progs if not at
>>>
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git
>
>>>
[...]
>> Hugo Mills keeps an integration branch with nearly all patches
>> to btrfs-progs applied. See
>>
>> http://www.spinics.net/lists/linux-btrfs/msg10594.html
>>
>> and for the last update
>>
>> http://www.spinics.net/lists/linux-btrfs/msg10890.html
> [...]
>
> Thanks.
>
> It might be worth adding a link to that to
> https://btrfs.wiki.kernel.org/index.php/Btrfs_source_repositories
>
> Note that it (integration-20110626) doesn't seem to include the fix
> in http://marc.info/?l=linux-btrfs&m=129238454714319&w=2 though.
Hi Hugo,

Can you please include that fix in the next release of your
integration branch for btrfs-progs-unstable?

Thanks,
Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJODFWKAAoJEJIcBJ3+Xkgi9VUQAI178VUW93+lHZV03YooS36z
YzCSd9UE4AK8n1H58gpQ2OWuLarTEkVB2iV2zn80DhKZioAlaJYA+mU9LG+c+dU6
IfwiyWrCFlaoyQn62gdmlFwgHcPglViSZX35LXuUbxdVzNM/KuCamp++ViL8TOZm
9vPd4UW98DxnvY+d4ui59Vt+5RWLxu5KHv+kRzXb5V4cMPRFmA4wrfyXkN8UdYLe
vJcJMFEy9JV2/fG+9thL+oglrb9pBkasHCXpoedUmJetf3eXpfnSZSiHRnYBlJY9
+dw1e4eh9uerJlwmCsqP1/TtGtyitwE8M/gXI8i+SkQKDNNqqa6RNf0axPNxfI9J
6jsqTzJCKcsV5VbdWMGJSEFanYmQ8rAI0BxJ+FrDlJIwZImnokFbxhrxUcYM4SpM
nNzbLV9bYHgx2LhotV+Iwoyfgb/S2vnnOnMoGs/LuaeDVO3fBnp1Ft1Ac6fi4T9q
wv/ot2TJ9tjLWGQOp1ACI+LzKd/DhtFs8p4NWaK/Tgc4Uy4VmcE+uLSIWh10s9Sg
UT0bEZMr7AXuDG9+QsjdnuOdLt/RjR2QAu4k3S3vU4ZHjGkYBXvYZd2pmaxCqJb1
aKtyGMf/apOYOWWyc8ia7dmm/dwA0plIjN30lWXfbx9YGlAzc3U4KYfgVyxfHjKx
lJkYHPcVpTSy4Y0AP6UJ
=uc4W
-END PGP SIGNATURE-

--
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: subvolumes missing from "btrfs subvolume list" output

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 30.06.2011 10:40, Stephane Chazelas wrote:
> 2011-06-30 08:47:38 +0800, Li Zefan:
>> Stephane Chazelas wrote:
>>> 2011-06-29 15:37:47 +0100, Stephane Chazelas: [...]
 I found
 http://thread.gmane.org/gmane.comp.file-systems.btrfs/8123/focus=8208




which looks like the same issue, with Li Zefan saying he had a
 fix, but I couldn't find any mention that it was actually
 fixed.

 Has anybody got any update on that?
>>> [...]
>>>
>>> I've found
>>> http://thread.gmane.org/gmane.comp.file-systems.btrfs/8232
>>>
>>
>> After that, I posted a patch to fix btrfs-progs, which Chris
>> aggreed on:
>>
>> http://marc.info/?l=linux-btrfs&m=129238454714319&w=2
> [...]
>
> Great. Thanks a lot
>
> It fixes my problem indeed.
>
> Which brings me to my next question: where to find the latest
> btrfs-progs if not at
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git
>
>
>
(that one hasn't been modified in 8 months)?
>
> Have changes for read-only subvolumes, per-directory settings...
> been applied to some publicly available repository?
Hugo Mills keeps an integration branch with nearly all patches to
btrfs-progs applied.
See

http://www.spinics.net/lists/linux-btrfs/msg10594.html

and for the last update

http://www.spinics.net/lists/linux-btrfs/msg10890.html

Cheers,
Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJODD9xAAoJEJIcBJ3+XkgiN1QP/RiO5KD4+wlEyVxe6WXq0xIE
GGsa4YrFWg/E9vKCw6LFVJAzdx3UdX3aM1EzDXoypX9jrtgEIbJbfjP635TAotDR
lYzvou0tovlxuyTBCbike7OVHz9faZwr91vpH9cNKFhDQMYXG0AIYO3gjv+lbTUc
m1CZNRaG1NUiyPTNoJi0Oj/e2cIAS7rhl1D26lLNfnwXMLA49a8EfaP526Qcg8eP
HqYWtBmm4cAPC7dNJbU9PELcJJ7hjnGE5ahZs/DwW6Usm8YEFZO6vA859oBp2REy
LwUCUcpnOSYjxD5iX4R7K7oPsHXdw8UkMACBzF1JgrqPS3rIi4bwRIp/ZA3M07AA
2B8eFD0oITxVK07vp9M64Sqms97V4cZxOtCkkCF+lEXppEaKj1lwpRoE4cmaAMW4
jA0sd8tgQw79Dy6/rBZyrxVJnXSmoWF3pisWIhHmFeAX+YnqT7ft7qXiWbQh7WMC
NFUw+1bagjshgZI+CxdY6stInJ+L+lSH4KTgtZb0mSxVnK440n/y/v5f9iDJ5js6
BkCZSYVjnite6wjZN5AYghZJfDCT4lXLN78dpeU6RWDD5/YlkJf4FkwFpHFVkHrO
M9x6cFRh74C5SiAPPWZUTT5g97mR4vuOzfTGwcSTv0ccaJzcxapUDZo50h30AbUA
TYTpSI2K2q3f+HvNJOPx
=ifgA
-END PGP SIGNATURE-

--
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: Integration branch updated

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 27.06.2011 14:43, David Sterba wrote:
> On Sun, Jun 26, 2011 at 10:10:22PM +0100, Hugo Mills wrote:
>> I've just updated the btrfs-progs integration branch I've been
>> keeping. Not a huge amount new since last time:
>>
>> Andreas Philipp (1):
>> print parent ID in btrfs subvolume list
>
> dunno if this has been mentioned already, but this change breaks
> xfstests/254 and needs a patch once merged.
Sorry, I was not aware of the problem with xfstests/254. But as far as
I see, xfstests/254 tests explicitly for subvolume/snapshot features
in btrfs and uses a specific filter to parse the output of btrfs
subvolume list. If this output changes (without introducing another
error), then "only" the test is broken.
Any suggestions on how to change the patch? Maybe adding a flag (-p ?)
to add the parent ID in the output and leave the standard output
untouched?

As mentioned in my original mail this patch is based on Hugos
integration branch integration-20110611.

Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJOCH+hAAoJEJIcBJ3+Xkgix4wQAKChVr6FITZedfI5s1/BE/gD
PRV8vjsYZQtUwNTQnUN1x+IEAgwpxmwOmBcQdOZ69zrxJlaozbu3fEn+EtDDdmBl
UcKRyCAEG2CP7lxGi6cerCq7e1m9EIw2wAd5ImnJZcUKUEOu/8oIeB2PPC1Z6J1s
edzgXzndk01LoxTBn6CiCX3CfMsWhr1h8RrVolWz0sEXUe8tw4cZT88Pd2IHSK1i
wvI3rXDAV7dTna4B9HOD9Uw1SqUfnIPOyGLs8JSguT8cJ74Z9bOP46gS4QX+yfDA
oPOj9LYBT4CyU06I/nYeL0BJkQPPtMa9KfTqE7UAgK0whPpG+MIaKkh4XXxaqDyC
IMn/rXVOpRDhe1CBOJvyUuGhJafkEQgP4RmvxWrA5ev6bL4nzvToK3FWmgEqx3Ki
ZuXEJ+05AVTlsFI5D+LtQSTI/xVq8xkJRSNFKGDuffKcm5/iWAO7M/qG1shg10c8
8p3WHGKr+vhuxNoK6DpeYYaAQYafXo2ijlmnE/8vecAFQCtxifpkshHJLPe+hB0Q
YDG2AKBsWhxFbPSfgSQdjlFiZrGR3FqVaivYWdy4d+nHI1M6dYVFHI0WCzY4fbjS
na74iuWsZfV209HasTk9wUSebYWJPn5YhmL7wWnD9auEI0G+nz+H9XeS2sAb66gX
4VF7Aa7Xdw1/PM4u/vgw
=RrQF
-END PGP SIGNATURE-

--
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: strange filefrag output on btrfs

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 14.06.2011 04:54, Li Zefan wrote:
> Andreas Philipp wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 13.06.2011 13:50, David Sterba wrote:
>>> On Sat, Jun 11, 2011 at 05:39:15PM +0200, Andreas Philipp
>>> wrote:
>>>> On one of my btrfs volumes I see a strange output from
>>>> filefrag when run against a particular large (~8GB) file.
>>>> filefrag and filefrag -v give me a different number of
>>>> extents, see below.
>>>>
>>>> aph@thor /mnt/nutshell $ sudo filefrag -v funtoo.img | grep
>>>> extents funtoo.img: 2624 extents found aph@thor /mnt/nutshell
>>>> $ sudo filefrag funtoo.img | grep extents funtoo.img: 2653
>>>> extents found
>>>
>>> is the file open and being written to? did you run sync before
>>> the first command?
>> The file is not open. Yes, I have run sync before the first
>> command. Now, I tested again with a copy of file but the results
>> is more or less the same.
>>
>> aph@thor /mnt/nutshell $ cp funtoo.img funtoo.1.img aph@thor
>> /mnt/nutshell $ sync aph@thor /mnt/nutshell $ sudo filefrag -v
>> funtoo.img funtoo.1.img | grep extents funtoo.img: 2624 extents
>> found funtoo.1.img: 57 extents found aph@thor /mnt/nutshell $
>> sudo filefrag funtoo.img funtoo.1.img | grep extents funtoo.img:
>> 2653 extents found funtoo.1.img: 311 extents found
>>
>
> If you look into the source code of filefrag, you'll know why.
>
> There are two ways to calc the extent number, depending on whether
> verbose option is turned on or not.
>
> In the verbose mode, it will check if the next extent is adjacent
> to the prev extent in the physical position, and in this case they
> are considered to be one extent.
>
> That's why the number returned in verbose mode is smaller.
Thank you for this explanation.

Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJN9wmvAAoJEJIcBJ3+XkgiIWgQAL0+SLwnc6V6nar30rG6wCt+
czTTy7wFgdP5oYby9NMj2a5YifxG2XBa+Hnw3doLSxTHv4i7WqouaFeT4OotBzb+
jV8GBAn3vRyGlV0mfEx1PHzqUJNzUpJHZpWKvKx4JW91z3gZ/FdXEhbZXNyTVvPm
WtaLXz71CMtCSy81TN437T92H7yvv4SxiRubbe+IuBpKCJaIA1eH2yoJ+72yDNKH
TS74hvfYoDXngxZry4EA2/3mGTOq3PMSljWBw76pqx47KhsZged0ZN+YA8th7iiK
H3Pm3m19yzvt5niA5aS/ilwR50pKE2LI2dq7kkc2yjol/A86iUmIkAEm94Bv7a/3
hdBHslzqZpb2sWaQB2qjDA9aWGyDld3B2C1a+CiYSr0kqtPRlWKPPCQiDNibxrMp
cC2vT92OCoJMnsz7OC3nQN+UZAzBTnx7deFVAlgxnLrsuVT2IZMfxeurTLGJy0vG
zygp7pXdLbj4pzvLcIbf53DQ8wsSfQfLlMDec7wj+TpDLWCuBLQRVmWIKsc1ovMb
epoBihD4xJZguaeQAsyxBuFgYNoWCj0ebxWejGIYvilCZ8SJflN8/dEN3HaT8haR
9k6qdNB9cNULggs4dN8zvB530InDNxJHuI67hRcdLs+VDcWHjCdXmfcgn3Lz5km4
wDAlG4uZi/T5Pqz1Eqvq
=NrYD
-END PGP SIGNATURE-

--
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: strange filefrag output on btrfs

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 13.06.2011 13:50, David Sterba wrote:
> On Sat, Jun 11, 2011 at 05:39:15PM +0200, Andreas Philipp wrote:
>> On one of my btrfs volumes I see a strange output from filefrag when
>> run against a particular large (~8GB) file. filefrag and filefrag -v
>> give me a different number of extents, see below.
>>
>> aph@thor /mnt/nutshell $ sudo filefrag -v funtoo.img | grep extents
>> funtoo.img: 2624 extents found
>> aph@thor /mnt/nutshell $ sudo filefrag funtoo.img | grep extents
>> funtoo.img: 2653 extents found
>
> is the file open and being written to? did you run sync before the first
> command?
The file is not open. Yes, I have run sync before the first command.
Now, I tested again with a copy of file but the results is more or
less the same.

aph@thor /mnt/nutshell $ cp funtoo.img funtoo.1.img
aph@thor /mnt/nutshell $ sync
aph@thor /mnt/nutshell $ sudo filefrag -v funtoo.img funtoo.1.img |
grep extents
funtoo.img: 2624 extents found
funtoo.1.img: 57 extents found
aph@thor /mnt/nutshell $ sudo filefrag funtoo.img funtoo.1.img | grep
extents
funtoo.img: 2653 extents found
funtoo.1.img: 311 extents found

Thanks,
Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJN9inZAAoJEJIcBJ3+XkgiADgP/1+B26+vvEhb2cFy64gCh9c1
eeJJXgZgQsMkq4ScTwmdgBkG49XtFRao+IAJLT8NEEYfWK2s/e7COK5KvjqHQP6T
Z64TKo/SKD3YaskszZEO30fM/A9pXcsDDRaCgOXJosCjRfl2vNyxvSMjnRRGEGGL
F4qI9sr9pkZrqbzwIrhPFBm1etkwMOOrXyqByg/VQoNxTts6xZ9hz0l42qOhrjXW
EZ1zLRrDqd0HTBPmrkntG4yACBW4/eJf0vPPn7cNRFf1a6ts9UTAgEOkobgP4tho
D+mGle5bPElyB72tcQ2jutk9+qr89VrUjrNHNHU3QAI9ZtvWLeHIS1P2PkiXk/s2
xQKL83V8QGoeK8BQTB2exMf7cBrgoVs4IfTcXaQyperFRFTYtjQ78J8p2iPvwTKY
6/4LkHkIEPJO3IZ81TFv1Vm5wefGqMWnpTRgvzLv52UlbNEkdcvdNM5IWGiIhFD6
cVQohZuHaTidhn2ancBVd3qE3oYMiBQknvKG39seUw8zTRixz7Ac+/uF7kcQSP6U
4RatjRADGN99Kt4ydwpZbIBiDQxttR+Js/sv8E8skqll96LeT+DVzMh2JRx+iy93
eatIlrTIgoPfi3Oo+NUXczMfamYfG7UcVhBUxDlQUTtKPAhPHmXvE9pkjqIJ5sxD
3mkSkEZ6ZXGujyIPXnfQ
=Yx0a
-END PGP SIGNATURE-

--
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

[PATCH] print parent ID in btrfs suvolume list

[Andreas Philipp]

There was some discussion on "where" subvolumes live in. Why do we not
simply print the parent ID for each subvolume in btrfs subvolume list.
This patch adds this functionality.

Signed-off-by: Andreas Philipp 
---
 btrfs-list.c |   10 --
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/btrfs-list.c b/btrfs-list.c
index f804dfc..a57ec4c 100644
--- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -203,6 +203,7 @@ static int add_root(struct root_lookup *root_lookup,
 static int resolve_root(struct root_lookup *rl, struct root_info *ri)
 {
u64 top_id;
+   u64 parent_id = 0;
char *full_path = NULL;
int len = 0;
struct root_info *found;
@@ -233,6 +234,11 @@ static int resolve_root(struct root_lookup *rl, struct 
root_info *ri)
}
 
next = found->ref_tree;
+   /* record the first parent */
+   if ( parent_id == 0 ) {
+   parent_id = next;
+   }
+
/* if the ref_tree refers to ourselves, we're at the top */
if (next == found->root_id) {
top_id = next;
@@ -249,8 +255,8 @@ static int resolve_root(struct root_lookup *rl, struct 
root_info *ri)
break;
}
}
-   printf("ID %llu top level %llu path %s\n",
-  (unsigned long long)ri->root_id, (unsigned long long)top_id,
+   printf("ID %llu parent %llu top level %llu path %s\n",
+  (unsigned long long)ri->root_id, (unsigned long long) parent_id, 
(unsigned long long)top_id,
   full_path);
free(full_path);
return 0;
-- 
1.7.3.4

--
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

strange filefrag output on btrfs

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Hi,

On one of my btrfs volumes I see a strange output from filefrag when
run against a particular large (~8GB) file. filefrag and filefrag -v
give me a different number of extents, see below.

aph@thor /mnt/nutshell $ sudo filefrag -v funtoo.img | grep extents
funtoo.img: 2624 extents found
aph@thor /mnt/nutshell $ sudo filefrag funtoo.img | grep extents
funtoo.img: 2653 extents found

Thanks,
Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJN84wiAAoJEJIcBJ3+XkgikzsQAKlH4dMcDMAplulM67TNUDRy
hMwQhgpkLTBfvB7SRcNImojPwj2TQq6CXWHqk+yjufN6Mz4Tb1F5vWbgPwQOkC3S
BNtNCJrua6COO2ijOv12UubTY6qQZqXSXNB2be5SVeh9Jt+DUZ55EJRUlhbPb7al
xhXIRNzIW4P0TfTfLgrQ4cZT+89FGilMe0x4YAw6TCl50f28X7Xjj94UHurM/wzX
eX2rR37GALSOw2CwIR2m9fmTOPXw61puXyx2ddO4iv3KWmu8lpp9Cl7QkacSKpOd
kxg0jFVAGj7NAeZU4ekVqZq0GVOqlNEwYfAZyGPI6D6PfO+Fj7l+hWh2aohv0GsL
xU1mcN9d7X+dvwt4NwbAS3H+ZlHIwJeRIdKyFwvMu3gyLmASuDJIZfFkomFzSfjN
DNMWvJdXoB4NZoi4I4cIIrQkcVHwglz3NjjCTErbvKHP7oALXqKGVaB2jIQQCOzz
gi201uGWaOM/tbIUGUxe9nL2cMfID+frMtBng7Q0muPiI57ek4vm7c2wA//2PK9S
/ZGfhzgZPOWQcULhzQ1/o9vIq6asnnd3eGAgEQAeuO90QAEMrnUY8MAsfK8m3i0L
EU7XyziQ3j2vXrN5HKkEJiKHjCrnK7/kFG0y0L5iWGBt0/29YMYqAqxDSvu7RXo/
laQ+Z6t5BcfRrP3I2lX/
=6T05
-END PGP SIGNATURE-

--
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

kernel BUG at fs/btrfs/extent-tree.c:1418!

[Andreas Philipp]

Hi,

On kernel 2.6.39 I encountered the following kernel BUG (see below). The btrfs 
filesystem (just application data) is 1.4TB big with several subvolumes, was 
created with -m raid1 -d raid0, and reports 108G free (via df -h) at the 
moment. The system has a dual core cpu. The load average is constantly 
increasing (reached 43 within 2 days), one core is 100% busy with kernel time 
and the other core is doing maybe up to 5% of kernel and user time while it 
spends the other 95% with io-wait. All process which tried to access the btrfs 
filesystem (for writing I guess) are stuck in D state. When the bug occured the 
vdr was doing a tv recording and noad was rereading another recording for 
marking all the ads.
Unfortunately, I am not at the site of the machine until Sunday evening and the 
machine did not react on a "shutdown -r", so I think I will have to push the 
power button then.
Is there anything I should take care of before hard rebooting?

Thanks,
Andreas Philipp

[ cut here ]
kernel BUG at fs/btrfs/extent-tree.c:1418!
invalid opcode:  [#1] SMP
last sysfs file: 
/sys/devices/pci:00/:00:1f.2/host2/target2:0:0/2:0:0:0/model
CPU 0
Modules linked in: xt_TCPMSS ipt_LOG ipt_REDIRECT xt_tcpudp ipt_MASQUERADE 
iptable_raw xt_comment iptable_nat ipt_REJECT bridge stp llc iptable_mangle 
nf_nat_tftp nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 
nf_nat_ftp nf_nat_amanda nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 ts_kmp 
nf_conntrack_amanda nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip 
nf_conntrack_proto_sctp nf_conntrack_pptp nf_conntrack_proto_gre 
nf_conntrack_netlink nfnetlink nf_conntrack_netbios_ns nf_conntrack_broadcast 
nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp iptable_filter xt_DSCP 
xt_dscp xt_string xt_NFQUEUE xt_multiport xt_mark xt_hashlimit xt_conntrack 
xt_connmark nf_conntrack ip_tables x_tables coretemp snd_seq_oss 
snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss nfsd tun btrfs 
zlib_deflate lzo_compress cpufreq_ondemand cpufreq_stats acpi_cpufreq 
freq_table mperf zl10353 em28xx_dvb snd_hda_codec_hdmi tda826x tda10086 lnbp21 
stb6100 stb0899 tuner_xc2028 nvidia(P)
tuner tvp5150 snd_hda_codec_realtek snd_hda_intel snd_hda_codec budget 
budget_core saa7146 uvcvideo mantis mantis_core snd_usb_audio em28xx snd_hwdep 
snd_usbmidi_lib snd_pcm ttpci_eeprom snd_rawmidi snd_timer rtc_cmos 
snd_seq_device rtc_core tpm_tis dvb_core v4l2_common i2c_i801 videodev 
ir_lirc_codec lirc_dev tpm videobuf_vmalloc videobuf_core snd rc_core 
snd_page_alloc joydev tveeprom serio_raw rtc_lib tpm_bios v4l2_compat_ioctl32 
processor fuse xfs nfs lockd sunrpc reiserfs raid456 async_raid6_recov 
async_memcpy async_pq raid6_pq async_xor xor async_tx raid0 dm_snapshot 
dm_mirror dm_region_hash dm_log scsi_wait_scan usbhid uhci_hcd usb_storage 
ehci_hcd usbcore sg ata_piix ahci libahci pata_jmicron

Pid: 5359, comm: btrfs-endio-wri Tainted: PW   2.6.39 #2/965P-DQ6
RIP: 0010:[]  [] 
lookup_inline_extent_backref+0xec/0x3fd [btrfs]
RSP: 0018:88012d7db9d0  EFLAGS: 00010202
RAX: 0001 RBX: 880059572a30 RCX: 0019
RDX: 0001 RSI: 8800 RDI: 880136a29ef8
RBP: 00b2 R08: 00800020 R09: 
R10: 0034 R11: 880059572a30 R12: 88013d018920
R13: 0001 R14: 001d R15: 0001
FS:  () GS:88013fc0() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 7faadc4c0c50 CR3: 00013419 CR4: 06f0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process btrfs-endio-wri (pid: 5359, threadinfo 88012d7da000, task 
88013bc80100)
Stack:
 0240 88012d7dbb60 00322d7da000 880059572a30
 001d052e 88013afdd800 00352d7dbc41 03b84e69e000
 880136a29828 88012d7dbab8 03b84e69e000 0bf000a8
Call Trace:
 [] ? insert_inline_extent_backref+0x63/0xec [btrfs]
 [] ? update_block_group+0x1d4/0x1f1 [btrfs]
 [] ? __btrfs_inc_extent_ref+0xb1/0x1e3 [btrfs]
 [] ? run_clustered_refs+0x69d/0x768 [btrfs]
 [] ? btrfs_run_delayed_refs+0xcd/0x1c0 [btrfs]
 [] ? __btrfs_end_transaction+0x66/0x1c1 [btrfs]
 [] ? btrfs_finish_ordered_io+0x2b3/0x2d8 [btrfs]
 [] ? end_bio_extent_writepage+0xa0/0x14a [btrfs]
 [] ? worker_loop+0x17f/0x47d [btrfs]
 [] ? btrfs_queue_worker+0x248/0x248 [btrfs]
 [] ? btrfs_queue_worker+0x248/0x248 [btrfs]
 [] ? kthread+0x7a/0x82
 [] ? kernel_thread_helper+0x4/0x10
 [] ? kthread_worker_fn+0x139/0x139
 [] ? gs_change+0xb/0xb
Code: 24 50 41 b9 01 00 00 00 44 8b 44 24 24 48 89 d9 48 8b 74 24 28 4c 89 e7 
e8 7e 63 ff ff 41 89 c5 83 f8 00 0f 8c e0 02 00 00 74 04 <0f> 0b eb fe 4c 8b 2b 
48 63 73 40 4c 89 ef 48 6b f6 19 48 83 c6
RIP  [] lookup_inline_extent_backref+0xec/0x3fd [btrfs]
 RSP

Re: strange btrfs sub list output

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 31.05.2011 19:40, C Anthony Risinger wrote:
> On Tue, May 31, 2011 at 5:00 AM, Stephane Chazelas
>  wrote:
>> 2011-05-27 13:49:52 +0200, Andreas Philipp: [...]
>>>> Thanks, I can understand that. What I don't get is how one
>>>> creates a subvol with a top-level other than 5. I might be
>>>> missing the obvious, though.
>>>>
>>>> If I do:
>>>>
>>>> btrfs sub create A btrfs sub create A/B btrfs sub snap A
>>>> A/B/C
>>>>
>>>> A, A/B, A/B/C have their top-level being 5. How would I get a
>>>> new snapshot to be a child of A/B for instance?
>>>>
>>>> In my case, 285, was not appearing in the btrfs sub list
>>>> output, 287 was a child of 285 with path "data" while all I
>>>> did was create a snapshot of 284 (path
>>>> u6:10022/vm+xfs@u8/xvda1/g8/v3/data in vol 5) in
>>>> u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30
>>>>
>>>> So I did manage to get a volume with a parent other than 5,
>>>> but I did not ask for it.
>> [...]
>>> Reconsidering the explanations on btrfs subvolume list in this
>>> thread I get the impression that a line in the output of btrfs
>>> subvolume list with top level other than 5 indicates that the
>>> backrefs from one subvolume to its parent are broken.
>>>
>>> What's your opinion on this?
>> [...]
>>
>> Given that I don't really get what the parent-child relationship
>> means in that context, I can't really comment.
>>
>> In effect, the snapshot had been created and was attached to the
>> right directory (but didn't appear in the sub list), and there
>> was an additional "data" volume that I had not asked for nor
>> created that had the snapshot above as parent and that did appear
>> in the sub list.
>>
>> It pretty much looks like a bug to me, I'd like to understand
>> more so that I can maybe try and avoid running into it again.
>
> i'm actually really interested in the conclusion to this thread
> because i _want_ to create subvols with a new parent ... i didn't
> realize this wasn't possible (nor the mount option) until reading
> this thread. this would give me a little more flexibility with
> initcpio hooks and the like vs. packing the btrfs root with tons of
> hidden files [subvols] or using IDs directly ...
>
> i tried absolutely everything i could think of to reproduce this
> but all subvols ended up having a top level id of `5`.
>
> ... so, is there any known way to _purposefully_ create parented
> subvols with the current tools?
Hopefully, I can help clarify this a little bit. In fact, this is the
'usual' case. With the attached patch to the master branch of
btrfs-progs-unstable you can 'watch' how the btrfs subvolume list
command builds the full path of the listed subvolumes. Additionally,
it gives you the IDs of the parent subvolumes. See the following example.

ID 256 top level 5 path test1
ID 257 top level 256 path test1.1
ID 257 top level 5 path test1/test1.1
ID 258 top level 5 path test2
ID 259 top level 258 path test2.1
ID 259 top level 5 path test2/test2.1

- From the second line you see that subvolume ID 256 really is ID 257's
parent. Additionally, only test1 and test2 have parent ID 5 or in your
terminology are in the btrfs root.

diff --git a/btrfs-list.c b/btrfs-list.c
index 93766a8..e75d6cf 100644
- --- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -248,6 +248,9 @@ static int resolve_root(struct root_lookup *rl,
struct root_info *ri)
top_id = next;
break;
}
+
+   printf("ID %llu top level %llu path %s\n",
ri->root_id, next,
+  full_path);
}
printf("ID %llu top level %llu path %s\n", ri->root_id, top_id,
   full_path);
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJN5Th6AAoJEJIcBJ3+XkgiWNQP/jsWQymukrgESfqndQvrJwl6
QZOe5y9IMmV8jBDPot4EAVAQhLrG2twA1ALVvj+DfD0Ks9VATpmnP4QB39XIWlNz
/cRxoUev/Z8a0zNnXXneUsbJ1rYx5vX6R0yzRWiZ6Yd0EZ9GCRp+HvPRs5NNGGIc
0NZCQk1BOe+MAovSQpUbRtyfd4JcxdPEYkt29VySu2wrD02MdXVyzohegCzmUZWv
ou8COpWvquPmNvYHfudVir6r4BSEfqpIEkkGY61yts00rnnPXuOh1uZQKGyDuK/S
2o6EOAN3SIONEWts7nx95/IjfAbVa/XUmj+bhr2xJspH4Q93tr8rDns0XCCN/GYY
xTfMMUFajZHOhv5qjbUF9BFLAU62eKdw4zCPAmed4f/klBcXZ/Ri1pIBwaJv3CTp
J3camkJBwmTiSwTIIl1qTOMypv0xT602uiiegnBe/UAzz59+cSLDyWFXBc2QQoTV
jhJiLd281kjPqEqALMNJOOZ0pQ6hDxOoBqg7cA5VEY9619coQE93H6UXgtd0E4YX
U32bO7WypGbgd3HuNDWd44p4gVYR/Mzu8symvjJDKg5iChLkBEmYyN8hAGryYhtO
mZBWntTxYPm+Twkf+ovAtVpLGV5Gr1kfGln5lsmsIn1bPW8ZnVbWIDhulD1lQSVw
Th5rDp6lY0ZBe4+mbOXy
=M8dp
-END PGP SIGNATURE-

--
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: strange btrfs sub list output

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 27.05.2011 13:30, Stephane Chazelas wrote:
> 2011-05-27 10:45:23 +0100, Hugo Mills: [...]
>>> How could a "subvolume 285" become a "top level"?
>>
>>> How does one get a subvolume with a top-level other than "5"?
>>
>> This just means that subvolume 287 was created (somewhere)
>> inside subvolume 285.
>>
>> Due to the way that the FS trees and subvolumes work, there's no
>> global namespace structure in btrfs; that is, there's no single
>> data structure that represents the entirety of the file/directory
>> hierarchy in the filesystem. Instead, it's broken up into these
>> sub-namespaces called subvolumes, and we only record parent/child
>> relationships for each subvolume separately. The "full path" you
>> get from "btrfs subv list" is reconstructed from that information
>> in userspace(*).
> [...]
>
> Thanks, I can understand that. What I don't get is how one creates
> a subvol with a top-level other than 5. I might be missing the
> obvious, though.
>
> If I do:
>
> btrfs sub create A btrfs sub create A/B btrfs sub snap A A/B/C
>
> A, A/B, A/B/C have their top-level being 5. How would I get a new
> snapshot to be a child of A/B for instance?
>
> In my case, 285, was not appearing in the btrfs sub list output,
> 287 was a child of 285 with path "data" while all I did was create
> a snapshot of 284 (path u6:10022/vm+xfs@u8/xvda1/g8/v3/data in vol
> 5) in u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30
>
> So I did manage to get a volume with a parent other than 5, but I
> did not ask for it.
Reconsidering the explanations on btrfs subvolume list in this thread
I get the impression that a line in the output of btrfs subvolume list
with top level other than 5 indicates that the backrefs from one
subvolume to its parent are broken.

What's your opinion on this?

Thanks,
Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJN34/fAAoJEJIcBJ3+XkgiTVcP/iQ62XnEAS0rVGOl+0DNqySb
5A5N3/pzhgzOdMhldJYtgg0K60lV0qs0H31ITgOdGUtpEXibybU/6Yuy2yIfqx0T
3OQCb2KE8la2hlh472aTuIN3beljFYzPu89KVrGaT6kD7lABRXkCG5y1Y5+fvVXI
gtq5/mCqvyaxxUMTppgzLHwtt0YVICZeCDmALMtsVe1DMr0uT5QI0XY+4Glpl7AJ
1G6Plyr7qciOwdRgvM/7NkHl/gsJ4GEvIOSVFiBM4Hb8fX7APy/C//sIPfD2Kg5K
7B6sJMpS2i87uEsrr+w8j7nLWn9Y/255W89r/cG3uISDFRn/RDs9xEnRCfEXb6qf
ZeBPVfv9+pN6mmwrfUOJr4pb44f9/UgTC+udCfzKm1yWVci895NIGsfJgYfA0OOf
GRnCWVRwFStiUGf0uSRH0yJAW5ozI8DzDnDKzByFpMcmw3eVNq5usCftA4XxVi7r
Wu/v9z6DNdHj7ibsSdeYXAmVGpwennILPeEvGWDbMB/OZIDKC3s75yCzXIhxWpya
zR5jGDbGj9IkvUhSAwW0afFqBK+bZny/SJsqA0vFH7Emao0CG1FIJVlN7/S6OSg1
Dtye//ocjhO0kf3OX3hj689n4/mvaBZeVArCz5vJzG2wEcRZTF4DZ4ApsUjne0LC
q4L2n9nLM4yeAs+YjFx/
=R53y
-END PGP SIGNATURE-

--
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: strange btrfs sub list output

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 27.05.2011 11:45, Hugo Mills wrote:
> On Fri, May 27, 2011 at 10:30:29AM +0100, Stephane Chazelas wrote:
>> 2011-05-27 10:12:24 +0100, Hugo Mills:
>> [skipped useful clarification]
>>>
>>> That's all rather dense, and probably too much information. Hope
>>> it's helpful, though.
>> [...]
>>
>> It is, thanks.
>>
>> How would one end up in a situation where the output of "btrfs
>> sub list ." has:
>>
>> ID 287 top level 285 path data
>>
>> How could a "subvolume 285" become a "top level"?
>
>> How does one get a subvolume with a top-level other than "5"?
>
> This just means that subvolume 287 was created (somewhere) inside
> subvolume 285.
>
> Due to the way that the FS trees and subvolumes work, there's no
> global namespace structure in btrfs; that is, there's no single data
> structure that represents the entirety of the file/directory hierarchy
> in the filesystem. Instead, it's broken up into these sub-namespaces
> called subvolumes, and we only record parent/child relationships for
> each subvolume separately. The "full path" you get from "btrfs subv
> list" is reconstructed from that information in userspace(*).
>
> Hugo.
>
> (*) Here's how it does it:
>
> The userspace tool gets a list of every subvolume by looking at the FS
> tree. It uses the corresponding back-refs to get the inode that
> represents each of those FS trees inside its parent:
>
> Subvol inode in subvol
> 256 991 5
> 257 896 256
> 258 1073 257
>
> From the inode numbers, it can then recursively walk back up the
> directory path to the top of each subvolume:
>
> Subvol inode in subvol relative path
> 256 991 5 henry
> 257 896 256 edward/mary
> 258 1073 257 elizabeth
>
> From that, it can then reconstruct the full pathnames, by walking back
> up the subvolume tree:
>
> subvol 258 is elizabeth in 257
> is edward/mary/elizabeth in 256
> is henry/edward/mary/elizabeth in 5
Just one (hopefully) short question: A line in the ouput of btrfs
subvolume list like
ID 257 top level 5 path test1/test1.1
says that the subvolume with name test1.1 (the last segment of the
path) and ID 257 has the path test1/test1.1 starting at the top level
subvolume which has ID 5 ?

Thanks,
Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJN33ezAAoJEJIcBJ3+Xkgi3egP/25y7JjnHJ9ZfQ2TF0cVWlhh
4FSHKhXlokH7E8fMcBbwP6YTB2zJioRkdWKmzoNjAvLlL8QkI7PvljAipe7YMgai
Zq+FNzN2y6qkpNBhdpJC0rnURbtD7neDdcRCDF3uatP2p+m6UghfPyTfqX31h1qc
UOp+3r+HLvlhAtKILxRaIZHidpS9ThZyN2mFHyKbyMMCoFYRXlJwL8xurPWdInbQ
sgjDmXVstsnoTcDaCsdWfUkRiLyPeiieOgCiB0X+/GdEG/gE6ICtzOf93fIeJu/B
CdGoaOSz73UIPdXstqiawhKxB83Ly68GNfoc/mrjFEml91KalGUnq/6f/344u6mB
2Ipwn1dpeC5ImwZO+VEc1HSv/GPCWyotUFzjV8NB/CcYYehX8GiNY0cSaT0NjTzs
ycUOOJUTWHTmavdT8ryDILPqSsqzMnN9NnrjJhs7EjEXSkvRxNQ4vUNOsWvCPjJl
HlooInMQ8/QTBkBLPkkiHWmhNuUaMPH6DJ85v6RNpFLiyf9TFDzBJvvyrZbkWx2y
tIvg8C1oKuZ1iulZidfY36h2wf4u/DuYgNYPSL0vsdOfABStn9MBeqPbqeF6fF42
AJ0gzVd+cqIWiFbnXEi4Zxt72l1DViLqe3Rxij2u00QOPRMtgGoKcwY7WmLKBnU5
1/vjmYvTJNnShewXMvsh
=zCSk
-END PGP SIGNATURE-

--
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: strange btrfs sub list output

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 27.05.2011 11:12, Hugo Mills wrote:
> On Fri, May 27, 2011 at 09:47:33AM +0100, Stephane Chazelas wrote:
>> 2011-05-27 10:21:03 +0200, Andreas Philipp:
>> [...]
>>>> What do those top-level IDs mean by the way?
>>> The top-level ID associated with a subvolume is NOT the ID of this
>>> particular subvolume but of the subvolume containing it. Since the
>>> "root/initial" (sub-)volume has always ID 0, the subvolumes of "depth"
>>> 1 will all have top-level ID set to 0. You need those top-level IDs to
>>> correctly mount a specific subvolume by name.
>>>
>>> # mount /dev/dummy -o subvol=,subvolrootid=
>>> /mountpoint
>>>
>>> Of course, you do need them, if you specify the subvolume to mount by
>>> its ID.
>> [...]
>>
>> Thanks Andreas for pointing that subvolrootid (might be worth
>> adding it to
>> https://btrfs.wiki.kernel.org/index.php/Getting_started#Mount_Options
>> BTW).
>>
>> In my case, on a freshly made btrfs file system, subvolumes have
>> top-level 5. (and neither volume with id 0 or 5 appear in the
>> btrfs sub list).
>>
>> All the top-levels are 5, and I don't even know how to create a
>> subvolume with a different top-level there, so I wonder how that
>> subvol that I had created with
>
> Actually, top-level subvolume ID=0 is a fiction. Internally, each
> subvolume is a separate FS tree (an FS tree in btrfs is a btree
> containing all of the inode and directory information for some
> subvolume). These trees are all referred to by a tree called the "root
> tree", which indexes all of the btrees in the filesystem.
>
> The root tree has a unique reference ID for each tree that it
> points to: most of the trees (extent tree, device tree, etc) have
> fixed and well-known IDs smaller than 256. The FS tree for the
> top-level subvolume -- the one that doesn't show up on a subvolume
> list -- always has ID 5. Hence the containing subvolume for most of
> your subvolumes is 5. The FS trees for the non-top-level subvolumes
> have IDs starting at 256 and increasing monotonically.
>
> Internally, there's a bit of a fiddle in the API, where a request
> for a subvolume ID of 0 is (sometimes) translated to an ID of 5. It's
> not always done, I think, and those cases where a subvol ID of 0
> doesn't get you the top-level subvolume should be treated as bugs.
Thank you for all this information. Once I had a such a situation,
where mount with subvolid=0 did not mount the top-level subvolume. I
will try to recreate it with a recent kernel.

Thanks,
Andreas

>
> That's all rather dense, and probably too much information. Hope
> it's helpful, though.
>
> Hugo.
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJN323eAAoJEJIcBJ3+XkgiFe8QALC9pa9DwygWNhULHF1jGoqY
+sHCvgD5WazkcquFD3xWg2pc52rnvDWpdeJAPw+6DzViCqnrk6lICyhhvjnAbm8a
h/87/7cV2CZbcVn/v283iuPLsok+HXsiyoMUHSEOhSCAE8CvveZbK7LtMSxagQpv
+e9TM9HUImw6UweYZ2LwMXY/Wu1z9yBaG/JuOq2MkslLniFekKaIPe8eZD4aej3o
RFkVKplvx3egu5lVJMDaK4rpL8xrQVxE4G8CtHLvVKRzJVHs8V3XTccaXmwpDks6
sZ+lzeU2+lNg+776K9+saXOuT9Ytuo0rpcDiEUAYxBO2DxSmbV2NArYkTLo0C3Sf
32+ecoqtZeNJH/v9a68+Pq0UH5cualLROGwyoc+MgqqIB+4zFq+nuTqk9eGtKchh
2YxQePXejnVsga8wgFMFSDYYaGKtfYUDKM+loq5XA/1A9bqjprIC40ovc3AHcJID
eqb861TEGXDBMajhFlLICk4YxyLd87ze6BOa4NxWwpVjkLW4HHPplsbW6EkTJBv6
bVwKDIpE4bmIpovIhRwxo5Eba4DNRtHrRD7U+2Ep+Juxx8n3y6DQD+qm40mOEtG0
oAhpVE/rKcR6FTxHPWon6lGH6D51bDDVOxVTwAyzETGbRA+eSA3nP05dtisXjEB2
07UBm2s0wHX7oQKOiATE
=R/Ih
-END PGP SIGNATURE-

--
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: strange btrfs sub list output

[Andreas Philipp]

On 27.05.2011 10:01, Stephane Chazelas wrote:
> 2011-05-26 22:22:03 +0100, Stephane Chazelas: [...]
>> I get a btrfs sub list output that I don't understand:
>>
>> # btrfs sub list /backup/ ID 257 top level 5 path
>> u1/linux/lvm+btrfs/storage/data/data ID 260 top level 5 path
>> u2/linux/lvm/linux/var/data ID 262 top level 5 path
>> u1/linux/lvm+btrfs/storage/data/snapshots/2010-10-11 ID 263 top
>> level 5 path u2/linux/lvm/linux/home/snapshots/2011-04-07 ID 264
>> top level 5 path u2/linux/lvm/linux/root/snapshots/2011-04-07 ID
>> 265 top level 5 path u2/linux/lvm/linux/var/snapshots/2011-04-07
>> ID 266 top level 5 path
>> u1/linux/lvm+btrfs/storage/data/snapshots/2010-10-26 ID 267 top
>> level 5 path u1/linux/lvm+btrfs/storage/data/snapshots/2010-11-08
>> ID 268 top level 5 path
>> u1/linux/lvm+btrfs/storage/data/snapshots/2010-11-22 ID 269 top
>> level 5 path u1/linux/lvm+btrfs/storage/data/snapshots/2010-12-15
>> ID 270 top level 5 path
>> u2/linux/lvm/linux/home/snapshots/2011-04-14 ID 271 top level 5
>> path u2/linux/lvm/linux/root/snapshots/2011-04-14 ID 272 top
>> level 5 path u2/linux/lvm/linux/var/snapshots/2011-04-14 ID 273
>> top level 5 path
>> u1/linux/lvm+btrfs/storage/data/snapshots/2010-12-29 ID 274 top
>> level 5 path u1/linux/lvm+btrfs/storage/data/snapshots/2011-01-26
>> ID 275 top level 5 path
>> u1/linux/lvm+btrfs/storage/data/snapshots/2011-03-07 ID 276 top
>> level 5 path u1/linux/lvm+btrfs/storage/data/snapshots/2011-04-01
>> ID 277 top level 5 path u2/linux/lvm/linux/home/data ID 278 top
>> level 5 path u2/linux/lvm/linux/home/snapshots/2011-04-27 ID 279
>> top level 5 path u2/linux/lvm/linux/root/snapshots/2011-04-27 ID
>> 280 top level 5 path u2/linux/lvm/linux/var/snapshots/2011-04-27
>> ID 281 top level 5 path u3:10022/vm+xfs@u9/xvda1/g1/v4/data ID
>> 282 top level 5 path
>> u3:10022/vm+xfs@u9/xvda1/g1/v4/snapshots/2011-05-19 ID 283 top
>> level 5 path u5/vm+xfs@u9/xvda1/g1/v5/data ID 284 top level 5
>> path u6:10022/vm+xfs@u8/xvda1/g8/v3/data ID 286 top level 5 path
>> u5/vm+xfs@u9/xvda1/g1/v5/snapshots/2011-05-24 ID 287 top level
>> 285 path data ID 288 top level 5 path
>> u4/vm+xfs@u9/xvda1/g1/v1/data ID 289 top level 5 path
>> u4/vm+xfs@u9/xvda1/g1/v1/snapshots/2011-03-11 ID 290 top level 5
>> path u4/vm+xfs@u9/xvda1/g1/v2/data ID 291 top level 5 path
>> u4/vm+xfs@u9/xvda1/g1/v2/snapshots/2011-05-11 ID 292 top level 5
>> path u4/vm+xfs@u9/xvda1/g1/v1/snapshots/2011-05-11
> [...]
>> There is no "/backup/data" directory. There is however a
>> /backup/u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30 that
>> contains the same thing as what I get if I mount the fs with
>> subvolid=287. And I did do a btrfs sub snap data
>> snapshots/2011-03/30 there.
>>
>> What could be the cause of that? How to fix it?
>>
>> In case that matters, there used to be more components in the
>> path of u6:10022/vm+xfs@u8/xvda1/g8/v3/data.
> [...]
>
> I tried deleting the
> /backup/u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30
> subvolume (what seems to be id 287) and I get:
>
> # btrfs sub delete snapshots/2011-03-30 Delete subvolume
> '/backup/u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30'
> ERROR: cannot delete
> '/backup/u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30'
>
> With a strace, it tells me:
>
> ioctl(3, 0x5000940f, 0x7fffc7841a80) = -1 ENOTEMPTY (Directory
> not empty)
>
> Then I realised that there was a "data" directory in there and
> that snapshots/2011-03-30 was actually id 285 (which doesn't appear
> in the btrfs sub list) and "snapshots/2011-03-30/data" is id 287.
>
> What do those top-level IDs mean by the way?
The top-level ID associated with a subvolume is NOT the ID of this
particular subvolume but of the subvolume containing it. Since the
"root/initial" (sub-)volume has always ID 0, the subvolumes of "depth"
1 will all have top-level ID set to 0. You need those top-level IDs to
correctly mount a specific subvolume by name.

# mount /dev/dummy -o subvol=,subvolrootid=
/mountpoint

Of course, you do need them, if you specify the subvolume to mount by
its ID.

Cheers,
Andreas Philipp

>
> Then I was able to delete snapshots/2011-03-30/data, but
> snapshots/2011-03-30 still didn't appear in the list.
>
> Then I was able to delete snapshots/2011-03-30 and recreate it,
> and this time it was fine.
>
> Still don't know what happened there.
>

--
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

[PATCH 2/5] Add support for read-only subvolumes.

[Andreas Philipp]

Use BTRFS_IOC_CREATE_SNAP_V2 instead of BTRFS_IOC_CREATE_SNAP and add
an option for the creation of a readonly snapshot.

Signed-off-by: Andreas Philipp 
---
 btrfs_cmds.c |   48 
 1 files changed, 40 insertions(+), 8 deletions(-)

diff --git a/btrfs_cmds.c b/btrfs_cmds.c
index 8031c58..9367bac 100644
--- a/btrfs_cmds.c
+++ b/btrfs_cmds.c
@@ -43,7 +43,7 @@
 
 #ifdef __CHECKER__
 #define BLKGETSIZE64 0
-#define BTRFS_IOC_SNAP_CREATE 0
+#define BTRFS_IOC_SNAP_CREATE_V2 0
 #define BTRFS_VOL_NAME_MAX 255
 struct btrfs_ioctl_vol_args { char name[BTRFS_VOL_NAME_MAX]; };
 static inline int ioctl(int fd, int define, void *arg) { return 0; }
@@ -310,13 +310,38 @@ int do_subvol_list(int argc, char **argv)
 int do_clone(int argc, char **argv)
 {
char*subvol, *dst;
-   int res, fd, fddst, len;
+   int res, fd, fddst, len, optind = 0, readonly = 0;
char*newname;
char*dstdir;
+   struct btrfs_ioctl_vol_args_v2  args;
 
-   subvol = argv[1];
-   dst = argv[2];
-   struct btrfs_ioctl_vol_args args;
+   memset(&args, 0, sizeof(args));
+
+   while (1) {
+   int c = getopt(argc, argv, "r");
+
+   if (c < 0)
+   break;
+   switch (c) {
+   case 'r':
+   optind++;
+   readonly = 1;
+   break;
+   default:
+   fprintf(stderr,
+   "Invalid arguments for subvolume snapshot\n");
+   free(argv);
+   return 1;
+   }
+   }
+   if (argc - optind < 2) {
+   fprintf(stderr, "Invalid arguments for subvolume snapshot\n");
+   free(argv);
+   return 1;
+   }
+
+   subvol = argv[optind+1];
+   dst = argv[optind+2];
 
res = test_issubvolume(subvol);
if(res<0){
@@ -372,11 +397,18 @@ int do_clone(int argc, char **argv)
return 12;
}
 
-   printf("Create a snapshot of '%s' in '%s/%s'\n",
-  subvol, dstdir, newname);
+   if (readonly) {
+   args.flags |= BTRFS_SUBVOL_RDONLY;
+   printf("Create a readonly snapshot of '%s' in '%s/%s'\n",
+  subvol, dstdir, newname);
+   } else {
+   printf("Create a snapshot of '%s' in '%s/%s'\n",
+  subvol, dstdir, newname);
+   }
+
args.fd = fd;
strcpy(args.name, newname);
-   res = ioctl(fddst, BTRFS_IOC_SNAP_CREATE, &args);
+   res = ioctl(fddst, BTRFS_IOC_SNAP_CREATE_V2, &args);
 
close(fd);
close(fddst);
-- 
1.7.4.1

--
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

[PATCH 4/5] Test the additional ioctl.

[Andreas Philipp]

Signed-off-by: Andreas Philipp 
---
 ioctl-test.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/ioctl-test.c b/ioctl-test.c
index 7cf3bc2..1c27d61 100644
--- a/ioctl-test.c
+++ b/ioctl-test.c
@@ -22,6 +22,7 @@ unsigned long ioctls[] = {
BTRFS_IOC_INO_LOOKUP,
BTRFS_IOC_DEFAULT_SUBVOL,
BTRFS_IOC_SPACE_INFO,
+   BTRFS_IOC_SNAP_CREATE_V2,
0 };
 
 int main(int ac, char **av)
-- 
1.7.4.1

--
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

[PATCH 3/5] Support the new parameters in do_clone(int argc, char** argv).

[Andreas Philipp]

Now 'btrfs subvolume snapshot' takes not two but only at least two
parameters. Additionally, the help message is updated accordingly.

Signed-off-by: Andreas Philipp 
---
 btrfs.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/btrfs.c b/btrfs.c
index 46314cf..f70d64b 100644
--- a/btrfs.c
+++ b/btrfs.c
@@ -44,9 +44,9 @@ static struct Command commands[] = {
/*
avoid short commands different for the case only
*/
-   { do_clone, 2,
- "subvolume snapshot", " [/]\n"
-   "Create a writable snapshot of the subvolume  with\n"
+   { do_clone, -2,
+ "subvolume snapshot", "[-r]  [/]\n"
+   "Create a writable/readonly snapshot of the subvolume  
with\n"
"the name  in the  directory."
},
{ do_delete_subvolume, 1,
-- 
1.7.4.1

--
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

[PATCH 5/5] Updated manpage for btrfs subvolume snapshot.

[Andreas Philipp]

Signed-off-by: Andreas Philipp 
---
 man/btrfs.8.in |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/man/btrfs.8.in b/man/btrfs.8.in
index 26ef982..b59bc6f 100644
--- a/man/btrfs.8.in
+++ b/man/btrfs.8.in
@@ -5,7 +5,7 @@
 .SH NAME
 btrfs \- control a btrfs filesystem
 .SH SYNOPSIS
-\fBbtrfs\fP \fBsubvolume snapshot\fP\fI  [/]\fP
+\fBbtrfs\fP \fBsubvolume snapshot\fP\fI [-r]  [/]\fP
 .PP
 \fBbtrfs\fP \fBsubvolume delete\fP\fI \fP
 .PP
@@ -70,10 +70,11 @@ command.
 .SH COMMANDS
 .TP
 
-\fBsubvolume snapshot\fR\fI  [/]\fR
-Create a writable snapshot of the subvolume \fI\fR with the name
-\fI\fR in the \fI\fR directory. If \fI\fR is not a
-subvolume, \fBbtrfs\fR returns an error.
+\fBsubvolume snapshot\fR\fI [-r]  [/]\fR
+Create a writable/readonly snapshot of the subvolume \fI\fR with the
+name \fI\fR in the \fI\fR directory. If \fI\fR is not a
+subvolume, \fBbtrfs\fR returns an error. If \fI-r\fR is given, the snapshot
+will be readonly.
 .TP
 
 \fBsubvolume delete\fR\fI \fR
-- 
1.7.4.1

--
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

[PATCH 1/5] Added support for an additional ioctl.

[Andreas Philipp]

Added BTRFS_IOC_SNAP_CREATE_V2 and struct btrfs_ioctl_vol_args_v2 as
defined in fs/btrfs/ioctl.h in the kernel sources.

Signed-off-by: Andreas Philipp 
---
 ioctl.h |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/ioctl.h b/ioctl.h
index 776d7a9..358f814 100644
--- a/ioctl.h
+++ b/ioctl.h
@@ -30,6 +30,17 @@ struct btrfs_ioctl_vol_args {
char name[BTRFS_PATH_NAME_MAX + 1];
 };
 
+#define BTRFS_SUBVOL_RDONLY(1ULL << 1)
+#define BTRFS_SUBVOL_NAME_MAX 4039
+
+struct btrfs_ioctl_vol_args_v2 {
+   __s64 fd;
+   __u64 transid;
+   __u64 flags;
+   __u64 unused[4];
+   char name[BTRFS_SUBVOL_NAME_MAX + 1];
+};
+
 struct btrfs_ioctl_search_key {
/* which root are we searching.  0 is the tree of tree roots */
__u64 tree_id;
@@ -132,6 +143,7 @@ struct btrfs_ioctl_space_args {
struct btrfs_ioctl_space_info spaces[0];
 };
 
+/* BTRFS_IOC_SNAP_CREATE is no longer used by the btrfs command */
 #define BTRFS_IOC_SNAP_CREATE _IOW(BTRFS_IOCTL_MAGIC, 1, \
   struct btrfs_ioctl_vol_args)
 #define BTRFS_IOC_DEFRAG _IOW(BTRFS_IOCTL_MAGIC, 2, \
@@ -169,4 +181,6 @@ struct btrfs_ioctl_space_args {
 #define BTRFS_IOC_DEFAULT_SUBVOL _IOW(BTRFS_IOCTL_MAGIC, 19, u64)
 #define BTRFS_IOC_SPACE_INFO _IOWR(BTRFS_IOCTL_MAGIC, 20, \
struct btrfs_ioctl_space_args)
+#define BTRFS_IOC_SNAP_CREATE_V2 _IOW(BTRFS_IOCTL_MAGIC, 23, \
+  struct btrfs_ioctl_vol_args_v2)
 #endif
-- 
1.7.4.1

--
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

[PATCH v2 0/5] Add user-space support for read-only snapshot creation.

[Andreas Philipp]

Changelog v2:
  - Fixed uninitialized variable (args).
  - Corrected order of patches to make everything compile.
  - Fixed some style errors.

There is kernel side support for the creation of read-only snapshots
for some time now, but I did not find any patches for the userspace
btrfs utilites. Thus I created this patchset which is tested and
working with kernel version 2.6.39-rc2.

Andreas Philipp (5):
  Added support for an additional ioctl.
  Add support for read-only subvolumes.
  Support the new parameters in do_clone(int argc, char** argv).
  Test the additional ioctl.
  Updated manpage for btrfs subvolume snapshot.

 btrfs.c|6 +++---
 btrfs_cmds.c   |   48 
 ioctl-test.c   |1 +
 ioctl.h|   14 ++
 man/btrfs.8.in |   11 ++-
 5 files changed, 64 insertions(+), 16 deletions(-)

-- 
1.7.4.1

--
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

[PATCH 5/5] Updated documentation for btrfs subvolume snapshot.

[Andreas Philipp]

Signed-off-by: Andreas Philipp 
---
 man/btrfs.8.in |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/man/btrfs.8.in b/man/btrfs.8.in
index 26ef982..b59bc6f 100644
--- a/man/btrfs.8.in
+++ b/man/btrfs.8.in
@@ -5,7 +5,7 @@
 .SH NAME
 btrfs \- control a btrfs filesystem
 .SH SYNOPSIS
-\fBbtrfs\fP \fBsubvolume snapshot\fP\fI  [/]\fP
+\fBbtrfs\fP \fBsubvolume snapshot\fP\fI [-r]  [/]\fP
 .PP
 \fBbtrfs\fP \fBsubvolume delete\fP\fI \fP
 .PP
@@ -70,10 +70,11 @@ command.
 .SH COMMANDS
 .TP
 
-\fBsubvolume snapshot\fR\fI  [/]\fR
-Create a writable snapshot of the subvolume \fI\fR with the name
-\fI\fR in the \fI\fR directory. If \fI\fR is not a
-subvolume, \fBbtrfs\fR returns an error.
+\fBsubvolume snapshot\fR\fI [-r]  [/]\fR
+Create a writable/readonly snapshot of the subvolume \fI\fR with the
+name \fI\fR in the \fI\fR directory. If \fI\fR is not a
+subvolume, \fBbtrfs\fR returns an error. If \fI-r\fR is given, the snapshot
+will be readonly.
 .TP
 
 \fBsubvolume delete\fR\fI \fR
-- 
1.7.4.1

--
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

[PATCH 3/5] Added support for an additional ioctl.

[Andreas Philipp]

Added BTRFS_IOC_SNAP_CREATE_V2 and struct btrfs_ioctl_vol_args_v2 as
defined in fs/btrfs/ioctl.h in the kernel sources.

Signed-off-by: Andreas Philipp 
---
 ioctl.h |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/ioctl.h b/ioctl.h
index 776d7a9..358f814 100644
--- a/ioctl.h
+++ b/ioctl.h
@@ -30,6 +30,17 @@ struct btrfs_ioctl_vol_args {
char name[BTRFS_PATH_NAME_MAX + 1];
 };
 
+#define BTRFS_SUBVOL_RDONLY(1ULL << 1)
+#define BTRFS_SUBVOL_NAME_MAX 4039
+
+struct btrfs_ioctl_vol_args_v2 {
+   __s64 fd;
+   __u64 transid;
+   __u64 flags;
+   __u64 unused[4];
+   char name[BTRFS_SUBVOL_NAME_MAX + 1];
+};
+
 struct btrfs_ioctl_search_key {
/* which root are we searching.  0 is the tree of tree roots */
__u64 tree_id;
@@ -132,6 +143,7 @@ struct btrfs_ioctl_space_args {
struct btrfs_ioctl_space_info spaces[0];
 };
 
+/* BTRFS_IOC_SNAP_CREATE is no longer used by the btrfs command */
 #define BTRFS_IOC_SNAP_CREATE _IOW(BTRFS_IOCTL_MAGIC, 1, \
   struct btrfs_ioctl_vol_args)
 #define BTRFS_IOC_DEFRAG _IOW(BTRFS_IOCTL_MAGIC, 2, \
@@ -169,4 +181,6 @@ struct btrfs_ioctl_space_args {
 #define BTRFS_IOC_DEFAULT_SUBVOL _IOW(BTRFS_IOCTL_MAGIC, 19, u64)
 #define BTRFS_IOC_SPACE_INFO _IOWR(BTRFS_IOCTL_MAGIC, 20, \
struct btrfs_ioctl_space_args)
+#define BTRFS_IOC_SNAP_CREATE_V2 _IOW(BTRFS_IOCTL_MAGIC, 23, \
+  struct btrfs_ioctl_vol_args_v2)
 #endif
-- 
1.7.4.1

--
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

[PATCH 4/5] Test the additional ioctl.

[Andreas Philipp]

Signed-off-by: Andreas Philipp 
---
 ioctl-test.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/ioctl-test.c b/ioctl-test.c
index 7cf3bc2..1c27d61 100644
--- a/ioctl-test.c
+++ b/ioctl-test.c
@@ -22,6 +22,7 @@ unsigned long ioctls[] = {
BTRFS_IOC_INO_LOOKUP,
BTRFS_IOC_DEFAULT_SUBVOL,
BTRFS_IOC_SPACE_INFO,
+   BTRFS_IOC_SNAP_CREATE_V2,
0 };
 
 int main(int ac, char **av)
-- 
1.7.4.1

--
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

[PATCH 2/5] Support the new parameters in do_clone(int argc, char** argv).

[Andreas Philipp]

Now 'btrfs subvolume snapshot' takes not two but only at least two
parameters. Additionally, the help message is updated accordingly.

Signed-off-by: Andreas Philipp 
---
 btrfs.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/btrfs.c b/btrfs.c
index 46314cf..f70d64b 100644
--- a/btrfs.c
+++ b/btrfs.c
@@ -44,9 +44,9 @@ static struct Command commands[] = {
/*
avoid short commands different for the case only
*/
-   { do_clone, 2,
- "subvolume snapshot", " [/]\n"
-   "Create a writable snapshot of the subvolume  with\n"
+   { do_clone, -2,
+ "subvolume snapshot", "[-r]  [/]\n"
+   "Create a writable/readonly snapshot of the subvolume  
with\n"
"the name  in the  directory."
},
{ do_delete_subvolume, 1,
-- 
1.7.4.1

--
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

[PATCH 1/5] Add support for read-only subvolumes.

[Andreas Philipp]

Use BTRFS_IOC_CREATE_SNAP_V2 instead of BTRFS_IOC_CREATE_SNAP and add
an option for the creation of a readonly snapshot.

Signed-off-by: Andreas Philipp 
---
 btrfs_cmds.c |   44 
 1 files changed, 36 insertions(+), 8 deletions(-)

diff --git a/btrfs_cmds.c b/btrfs_cmds.c
index 8031c58..baec675 100644
--- a/btrfs_cmds.c
+++ b/btrfs_cmds.c
@@ -43,7 +43,7 @@
 
 #ifdef __CHECKER__
 #define BLKGETSIZE64 0
-#define BTRFS_IOC_SNAP_CREATE 0
+#define BTRFS_IOC_SNAP_CREATE_V2 0
 #define BTRFS_VOL_NAME_MAX 255
 struct btrfs_ioctl_vol_args { char name[BTRFS_VOL_NAME_MAX]; };
 static inline int ioctl(int fd, int define, void *arg) { return 0; }
@@ -310,13 +310,34 @@ int do_subvol_list(int argc, char **argv)
 int do_clone(int argc, char **argv)
 {
char*subvol, *dst;
-   int res, fd, fddst, len;
+   int res, fd, fddst, len, optind = 0, readonly = 0;
char*newname;
char*dstdir;
 
-   subvol = argv[1];
-   dst = argv[2];
-   struct btrfs_ioctl_vol_args args;
+   while(1) {
+   int c = getopt(argc, argv, "r");
+   if (c < 0)
+   break;
+   switch(c) {
+   case 'r':
+   optind++;
+   readonly = 1;
+   break;
+   default:
+   fprintf(stderr, "Invalid arguments for 
subvolume snapshot\n");
+   free(argv);
+   return 1;
+   }
+   }
+   if (argc - optind < 2) {
+   fprintf(stderr, "Invalid arguments for defragment\n");
+   free(argv);
+   return 1;
+   }
+
+   subvol = argv[optind+1];
+   dst = argv[optind+2];
+   struct btrfs_ioctl_vol_args_v2  args;
 
res = test_issubvolume(subvol);
if(res<0){
@@ -371,12 +392,19 @@ int do_clone(int argc, char **argv)
fprintf(stderr, "ERROR: can't access to '%s'\n", dstdir);
return 12;
}
+   
+   if (readonly) {
+   args.flags |= BTRFS_SUBVOL_RDONLY;
+   printf("Create a readonly snapshot of '%s' in '%s/%s'\n",
+  subvol, dstdir, newname);
+   }
+   else
+   printf("Create a snapshot of '%s' in '%s/%s'\n",
+  subvol, dstdir, newname);
 
-   printf("Create a snapshot of '%s' in '%s/%s'\n",
-  subvol, dstdir, newname);
args.fd = fd;
strcpy(args.name, newname);
-   res = ioctl(fddst, BTRFS_IOC_SNAP_CREATE, &args);
+   res = ioctl(fddst, BTRFS_IOC_SNAP_CREATE_V2, &args);
 
close(fd);
close(fddst);
-- 
1.7.4.1

--
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

[PATCH 0/5] Add user-space support for read-only snapshot creation.

[Andreas Philipp]

There is kernel side support for the creation of read-only snapshots
for some time now, but I did not find any patches for the userspace
btrfs utilites. Thus I created this patchset which is tested and
working with kernel version 2.6.39-rc2.

Andreas Philipp (5):
  Add support for read-only subvolumes.
  Support the new parameters in do_clone(int argc, char** argv).
  Added support for an additional ioctl.
  Test the additional ioctl.
  Updated documentation for btrfs subvolume snapshot.

 btrfs.c|6 +++---
 btrfs_cmds.c   |   44 
 ioctl-test.c   |1 +
 ioctl.h|   14 ++
 man/btrfs.8.in |   11 ++-
 5 files changed, 60 insertions(+), 16 deletions(-)

-- 
1.7.4.1

--
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

[PATCH 5/5] Updated documentation for btrfs subvolume snapshot.

[Andreas Philipp]

Signed-off-by: Andreas Philipp 
---
 man/btrfs.8.in |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/man/btrfs.8.in b/man/btrfs.8.in
index 26ef982..b59bc6f 100644
--- a/man/btrfs.8.in
+++ b/man/btrfs.8.in
@@ -5,7 +5,7 @@
 .SH NAME
 btrfs \- control a btrfs filesystem
 .SH SYNOPSIS
-\fBbtrfs\fP \fBsubvolume snapshot\fP\fI  [/]\fP
+\fBbtrfs\fP \fBsubvolume snapshot\fP\fI [-r]  [/]\fP
 .PP
 \fBbtrfs\fP \fBsubvolume delete\fP\fI \fP
 .PP
@@ -70,10 +70,11 @@ command.
 .SH COMMANDS
 .TP
 
-\fBsubvolume snapshot\fR\fI  [/]\fR
-Create a writable snapshot of the subvolume \fI\fR with the name
-\fI\fR in the \fI\fR directory. If \fI\fR is not a
-subvolume, \fBbtrfs\fR returns an error.
+\fBsubvolume snapshot\fR\fI [-r]  [/]\fR
+Create a writable/readonly snapshot of the subvolume \fI\fR with the
+name \fI\fR in the \fI\fR directory. If \fI\fR is not a
+subvolume, \fBbtrfs\fR returns an error. If \fI-r\fR is given, the snapshot
+will be readonly.
 .TP
 
 \fBsubvolume delete\fR\fI \fR
-- 
1.7.4.1

--
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

[PATCH 4/5] Test the additional ioctl.

[Andreas Philipp]

Signed-off-by: Andreas Philipp 
---
 ioctl-test.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/ioctl-test.c b/ioctl-test.c
index 7cf3bc2..1c27d61 100644
--- a/ioctl-test.c
+++ b/ioctl-test.c
@@ -22,6 +22,7 @@ unsigned long ioctls[] = {
BTRFS_IOC_INO_LOOKUP,
BTRFS_IOC_DEFAULT_SUBVOL,
BTRFS_IOC_SPACE_INFO,
+   BTRFS_IOC_SNAP_CREATE_V2,
0 };
 
 int main(int ac, char **av)
-- 
1.7.4.1

--
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

[PATCH 3/5] Added support for an additional ioctl.

[Andreas Philipp]

Added BTRFS_IOC_SNAP_CREATE_V2 and struct btrfs_ioctl_vol_args_v2 as
defined in fs/btrfs/ioctl.h in the kernel sources.

Signed-off-by: Andreas Philipp 
---
 ioctl.h |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/ioctl.h b/ioctl.h
index 776d7a9..358f814 100644
--- a/ioctl.h
+++ b/ioctl.h
@@ -30,6 +30,17 @@ struct btrfs_ioctl_vol_args {
char name[BTRFS_PATH_NAME_MAX + 1];
 };
 
+#define BTRFS_SUBVOL_RDONLY(1ULL << 1)
+#define BTRFS_SUBVOL_NAME_MAX 4039
+
+struct btrfs_ioctl_vol_args_v2 {
+   __s64 fd;
+   __u64 transid;
+   __u64 flags;
+   __u64 unused[4];
+   char name[BTRFS_SUBVOL_NAME_MAX + 1];
+};
+
 struct btrfs_ioctl_search_key {
/* which root are we searching.  0 is the tree of tree roots */
__u64 tree_id;
@@ -132,6 +143,7 @@ struct btrfs_ioctl_space_args {
struct btrfs_ioctl_space_info spaces[0];
 };
 
+/* BTRFS_IOC_SNAP_CREATE is no longer used by the btrfs command */
 #define BTRFS_IOC_SNAP_CREATE _IOW(BTRFS_IOCTL_MAGIC, 1, \
   struct btrfs_ioctl_vol_args)
 #define BTRFS_IOC_DEFRAG _IOW(BTRFS_IOCTL_MAGIC, 2, \
@@ -169,4 +181,6 @@ struct btrfs_ioctl_space_args {
 #define BTRFS_IOC_DEFAULT_SUBVOL _IOW(BTRFS_IOCTL_MAGIC, 19, u64)
 #define BTRFS_IOC_SPACE_INFO _IOWR(BTRFS_IOCTL_MAGIC, 20, \
struct btrfs_ioctl_space_args)
+#define BTRFS_IOC_SNAP_CREATE_V2 _IOW(BTRFS_IOCTL_MAGIC, 23, \
+  struct btrfs_ioctl_vol_args_v2)
 #endif
-- 
1.7.4.1

--
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

[PATCH 2/5] Support the new parameters in do_clone(int argc, char** argv).

[Andreas Philipp]

Now 'btrfs subvolume snapshot' takes not two but only at least two
parameters. Additionally, the help message is updated accordingly.

Signed-off-by: Andreas Philipp 
---
 btrfs.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/btrfs.c b/btrfs.c
index 46314cf..f70d64b 100644
--- a/btrfs.c
+++ b/btrfs.c
@@ -44,9 +44,9 @@ static struct Command commands[] = {
/*
avoid short commands different for the case only
*/
-   { do_clone, 2,
- "subvolume snapshot", " [/]\n"
-   "Create a writable snapshot of the subvolume  with\n"
+   { do_clone, -2,
+ "subvolume snapshot", "[-r]  [/]\n"
+   "Create a writable/readonly snapshot of the subvolume  
with\n"
"the name  in the  directory."
},
{ do_delete_subvolume, 1,
-- 
1.7.4.1

--
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

[PATCH 1/5] Add support for read-only subvolumes.

[Andreas Philipp]

Use BTRFS_IOC_CREATE_SNAP_V2 instead of BTRFS_IOC_CREATE_SNAP and add
an option for the creation of a readonly snapshot.

Signed-off-by: Andreas Philipp 
---
 btrfs_cmds.c |   44 
 1 files changed, 36 insertions(+), 8 deletions(-)

diff --git a/btrfs_cmds.c b/btrfs_cmds.c
index 8031c58..baec675 100644
--- a/btrfs_cmds.c
+++ b/btrfs_cmds.c
@@ -43,7 +43,7 @@
 
 #ifdef __CHECKER__
 #define BLKGETSIZE64 0
-#define BTRFS_IOC_SNAP_CREATE 0
+#define BTRFS_IOC_SNAP_CREATE_V2 0
 #define BTRFS_VOL_NAME_MAX 255
 struct btrfs_ioctl_vol_args { char name[BTRFS_VOL_NAME_MAX]; };
 static inline int ioctl(int fd, int define, void *arg) { return 0; }
@@ -310,13 +310,34 @@ int do_subvol_list(int argc, char **argv)
 int do_clone(int argc, char **argv)
 {
char*subvol, *dst;
-   int res, fd, fddst, len;
+   int res, fd, fddst, len, optind = 0, readonly = 0;
char*newname;
char*dstdir;
 
-   subvol = argv[1];
-   dst = argv[2];
-   struct btrfs_ioctl_vol_args args;
+   while(1) {
+   int c = getopt(argc, argv, "r");
+   if (c < 0)
+   break;
+   switch(c) {
+   case 'r':
+   optind++;
+   readonly = 1;
+   break;
+   default:
+   fprintf(stderr, "Invalid arguments for 
subvolume snapshot\n");
+   free(argv);
+   return 1;
+   }
+   }
+   if (argc - optind < 2) {
+   fprintf(stderr, "Invalid arguments for defragment\n");
+   free(argv);
+   return 1;
+   }
+
+   subvol = argv[optind+1];
+   dst = argv[optind+2];
+   struct btrfs_ioctl_vol_args_v2  args;
 
res = test_issubvolume(subvol);
if(res<0){
@@ -371,12 +392,19 @@ int do_clone(int argc, char **argv)
fprintf(stderr, "ERROR: can't access to '%s'\n", dstdir);
return 12;
}
+   
+   if (readonly) {
+   args.flags |= BTRFS_SUBVOL_RDONLY;
+   printf("Create a readonly snapshot of '%s' in '%s/%s'\n",
+  subvol, dstdir, newname);
+   }
+   else
+   printf("Create a snapshot of '%s' in '%s/%s'\n",
+  subvol, dstdir, newname);
 
-   printf("Create a snapshot of '%s' in '%s/%s'\n",
-  subvol, dstdir, newname);
args.fd = fd;
strcpy(args.name, newname);
-   res = ioctl(fddst, BTRFS_IOC_SNAP_CREATE, &args);
+   res = ioctl(fddst, BTRFS_IOC_SNAP_CREATE_V2, &args);
 
close(fd);
close(fddst);
-- 
1.7.4.1

--
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

[PATCH 0/5] Add user-space support for read-only snapshot creation.

[Andreas Philipp]

There is kernel side support for the creation of read-only snapshots
for some time now, but I did not find any patches for the userspace
btrfs utilites. Thus I created this patchset which is tested and
working with kernel version 2.6.39-rc2.

Andreas Philipp (5):
  Add support for read-only subvolumes.
  Support the new parameters in do_clone(int argc, char** argv).
  Added support for an additional ioctl.
  Test the additional ioctl.
  Updated documentation for btrfs subvolume snapshot.

 btrfs.c|6 +++---
 btrfs_cmds.c   |   44 
 ioctl-test.c   |1 +
 ioctl.h|   14 ++
 man/btrfs.8.in |   11 ++-
 5 files changed, 60 insertions(+), 16 deletions(-)

-- 
1.7.4.1

--
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: [PATCH V3] Btrfs: fix subvolume mount by name problem when default mount subvolume is set

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Just a (probably) short question. This means, one now can mount any
subvolume which lies directly in another subvolume by name, as long as
one passes the correct subvolrootid=X mount option?

Thanks,
Andreas Philipp

On 06.04.2011 09:33, Zhong, Xin wrote:
> We create two subvolumes (meego_root and meego_home) in
> btrfs root directory. And set meego_root as default mount
> subvolume. After we remount btrfs, meego_root is mounted
> to top directory by default. Then when we try to mount
> meego_home (subvol=meego_home) to a subdirectory, it failed.
> The problem is when default mount subvolume is set to
> meego_root, we search meego_home in meego_root but can not find
> it. So the solution is to add a new mount option (subvolrootid)
> to specify subvol id of root and search subvol name in it. For
> our case, now we can use "-o subvolrootid=0,subvol=meego_home)
> to mount meego_home.
>
> Detail information can be found in meego bugzilla:
> https://bugs.meego.com/show_bug.cgi?id=15055
>
> Signed-off-by: Zhong, Xin 
> ---
> fs/btrfs/super.c | 42 +-
> 1 files changed, 33 insertions(+), 9 deletions(-)
>
> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> index db0a827..b85fe78 100644
> --- a/fs/btrfs/super.c
> +++ b/fs/btrfs/super.c
> @@ -156,7 +156,7 @@ enum {
> Opt_compress_type, Opt_compress_force, Opt_compress_force_type,
> Opt_notreelog, Opt_ratio, Opt_flushoncommit, Opt_discard,
> Opt_space_cache, Opt_clear_cache, Opt_user_subvol_rm_allowed,
> - Opt_enospc_debug, Opt_err,
> + Opt_enospc_debug, Opt_subvolrootid, Opt_err,
> };
>
> static match_table_t tokens = {
> @@ -186,6 +186,7 @@ static match_table_t tokens = {
> {Opt_clear_cache, "clear_cache"},
> {Opt_user_subvol_rm_allowed, "user_subvol_rm_allowed"},
> {Opt_enospc_debug, "enospc_debug"},
> + {Opt_subvolrootid, "subvolrootid=%d"},
> {Opt_err, NULL},
> };
>
> @@ -229,6 +230,7 @@ int btrfs_parse_options(struct btrfs_root *root,
char *options)
> break;
> case Opt_subvol:
> case Opt_subvolid:
> + case Opt_subvolrootid:
> case Opt_device:
> /*
> * These are parsed by btrfs_parse_early_options
> @@ -385,7 +387,7 @@ out:
> */
> static int btrfs_parse_early_options(const char *options, fmode_t flags,
> void *holder, char **subvol_name, u64 *subvol_objectid,
> - struct btrfs_fs_devices **fs_devices)
> + u64 *subvol_rootid, struct btrfs_fs_devices **fs_devices)
> {
> substring_t args[MAX_OPT_ARGS];
> char *opts, *orig, *p;
> @@ -426,6 +428,18 @@ static int btrfs_parse_early_options(const char
*options, fmode_t flags,
> *subvol_objectid = intarg;
> }
> break;
> + case Opt_subvolrootid:
> + intarg = 0;
> + error = match_int(&args[0], &intarg);
> + if (!error) {
> + /* we want the original fs_tree */
> + if (!intarg)
> + *subvol_rootid =
> + BTRFS_FS_TREE_OBJECTID;
> + else
> + *subvol_rootid = intarg;
> + }
> + break;
> case Opt_device:
> error = btrfs_scan_one_device(match_strdup(&args[0]),
> flags, holder, fs_devices);
> @@ -715,6 +729,7 @@ static int btrfs_get_sb(struct file_system_type
*fs_type, int flags,
> fmode_t mode = FMODE_READ;
> char *subvol_name = NULL;
> u64 subvol_objectid = 0;
> + u64 subvol_rootid = 0;
> int error = 0;
>
> if (!(flags & MS_RDONLY))
> @@ -722,7 +737,7 @@ static int btrfs_get_sb(struct file_system_type
*fs_type, int flags,
>
> error = btrfs_parse_early_options(data, mode, fs_type,
> &subvol_name, &subvol_objectid,
> - &fs_devices);
> + &subvol_rootid, &fs_devices);
> if (error)
> return error;
>
> @@ -786,15 +801,17 @@ static int btrfs_get_sb(struct file_system_type
*fs_type, int flags,
> s->s_flags |= MS_ACTIVE;
> }
>
> - root = get_default_root(s, subvol_objectid);
> - if (IS_ERR(root)) {
> - error = PTR_ERR(root);
> - deactivate_locked_super(s);
> - goto error_free_subvol_name;
> - }
> /* if they gave us a subvolume name bind mount into that */
> if (strcmp(subvol_name, ".")) {
> struct dentry *new_root;
> +
> + root = get_default_root(s, subvol_rootid);
> + if (IS_ERR(root)) {
> + error = PTR_ERR(root);
> + deactivate_locked_super(s);
> + goto error_free_subvol_name;
> + }
> +
> mutex_lock(&root->d_inode->i_mutex);
> new_root = lookup_one_len(subvol_name, root,
> strlen(subvol_name));
> @@ -815,6 +832,13 @@ static int btrfs_get_sb(struct file_system_type
*fs_type, int flags,
> }
> dput(root);
> root = new_root;
> + } else {
> + root = get_default_root(s, subvol_objectid);
> + if (IS_ERR(root)) {
> + error = PTR_ERR(root);
> + deactivate_l

Re: [RFC][PATCH] Btrfs: Fix uninitialized root flags for subvolumes

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 28.03.2011 04:01, Li Zefan wrote:
> root_item->flags and root_item->byte_limit are not initialized when
> a subvolume is created. This bug is not revealed until we added
> readonly snapshot support - now you mount a btrfs filesystem and you
> may find the subvolumes in it are readonly.
>
> To work around this problem, we steal a bit from
root_item->inode_item->flags,
> and use it to indicate if those fields have been properly initialized.
> When we read a tree root from disk, we check if the bit is set, and if
> not we'll set the flag and initialize the two fields of the root item.
>
> Reported-by: Andreas Philipp 
> Signed-off-by: Li Zefan 
Tested-by: Andreas Philipp 
> ---
> fs/btrfs/ctree.h | 4 
> fs/btrfs/disk-io.c | 4 +++-
> fs/btrfs/ioctl.c | 4 
> fs/btrfs/root-tree.c | 18 ++
> fs/btrfs/transaction.c | 1 +
> 5 files changed, 30 insertions(+), 1 deletions(-)
>
> diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
> index 8b4b9d1..ff6b991 100644
> --- a/fs/btrfs/ctree.h
> +++ b/fs/btrfs/ctree.h
> @@ -1284,6 +1284,8 @@ struct btrfs_root {
> #define BTRFS_INODE_NOATIME (1 << 9)
> #define BTRFS_INODE_DIRSYNC (1 << 10)
>
> +#define BTRFS_INODE_ROOT_ITEM_INIT (1 << 31)
> +
> /* some macros to generate set/get funcs for the struct fields. This
> * assumes there is a lefoo_to_cpu for every type, so lets make a simple
> * one for u8:
> @@ -2355,6 +2357,8 @@ int btrfs_find_dead_roots(struct btrfs_root
*root, u64 objectid);
> int btrfs_find_orphan_roots(struct btrfs_root *tree_root);
> int btrfs_set_root_node(struct btrfs_root_item *item,
> struct extent_buffer *node);
> +void btrfs_check_and_init_root_item(struct btrfs_root_item *item);
> +
> /* dir-item.c */
> int btrfs_insert_dir_item(struct btrfs_trans_handle *trans,
> struct btrfs_root *root, const char *name,
> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
> index 3e1ea3e..4f8dafc 100644
> --- a/fs/btrfs/disk-io.c
> +++ b/fs/btrfs/disk-io.c
> @@ -1184,8 +1184,10 @@ struct btrfs_root
*btrfs_read_fs_root_no_radix(struct btrfs_root *tree_root,
> root->commit_root = btrfs_root_node(root);
> BUG_ON(!root->node);
> out:
> - if (location->objectid != BTRFS_TREE_LOG_OBJECTID)
> + if (location->objectid != BTRFS_TREE_LOG_OBJECTID) {
> root->ref_cows = 1;
> + btrfs_check_and_init_root_item(&root->root_item);
> + }
>
> return root;
> }
> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
> index 5fdb2ab..2ff51e6 100644
> --- a/fs/btrfs/ioctl.c
> +++ b/fs/btrfs/ioctl.c
> @@ -294,6 +294,10 @@ static noinline int create_subvol(struct
btrfs_root *root,
> inode_item->nbytes = cpu_to_le64(root->leafsize);
> inode_item->mode = cpu_to_le32(S_IFDIR | 0755);
>
> + root_item.flags = 0;
> + root_item.byte_limit = 0;
> + inode_item->flags = cpu_to_le64(BTRFS_INODE_ROOT_ITEM_INIT);
> +
> btrfs_set_root_bytenr(&root_item, leaf->start);
> btrfs_set_root_generation(&root_item, trans->transid);
> btrfs_set_root_level(&root_item, 0);
> diff --git a/fs/btrfs/root-tree.c b/fs/btrfs/root-tree.c
> index 6a1086e..3e45c32 100644
> --- a/fs/btrfs/root-tree.c
> +++ b/fs/btrfs/root-tree.c
> @@ -471,3 +471,21 @@ again:
> btrfs_free_path(path);
> return 0;
> }
> +
> +/*
> + * Old btrfs forgets to init root_item->flags and root_item->byte_limit
> + * for subvolumes. To work around this problem, we steal a bit from
> + * root_item->inode_item->flags, and use it to indicate if those fields
> + * have been properly initialized.
> + */
> +void btrfs_check_and_init_root_item(struct btrfs_root_item *root_item)
> +{
> + u64 inode_flags = le64_to_cpu(root_item->inode.flags);
> +
> + if (!(inode_flags & BTRFS_INODE_ROOT_ITEM_INIT)) {
> + inode_flags |= BTRFS_INODE_ROOT_ITEM_INIT;
> + root_item->inode.flags = cpu_to_le64(inode_flags);
> + root_item->flags = 0;
> + root_item->byte_limit = 0;
> + }
> +}
> diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
> index 3d73c8d..f3d6681 100644
> --- a/fs/btrfs/transaction.c
> +++ b/fs/btrfs/transaction.c
> @@ -970,6 +970,7 @@ static noinline int create_pending_snapshot(struct
btrfs_trans_handle *trans,
> record_root_in_trans(trans, root);
> btrfs_set_root_last_snapshot(&root->root_item, trans->transid);
> memcpy(new_root_item, &root->root_item, sizeof(*new_root_item));
> + btrfs_check_and_init_root_item(new_root_item);
>
> root_flags = btrfs_root_flags(new_root_item);
> if (pending->readonly)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 

Re: read-only subvolumes?

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 23.03.2011 11:07, Andreas Philipp wrote:
>
> On 23.03.2011 10:25, Li Zefan wrote:
>>> Hi all,
>>>
>>> When I am creating subvolumes I get this strange behavior. If I
>>> create a subvolume with a name longer than 4 characters it is
>>> read-only, if the name is shorter than 5 characters the
>>> subvolume is writeable as expected. I think it is since I
>>> upgraded to kernel version 2.6.38 (I do not create subvolumes
>>> on a regular basis.). I will compile one of the latest 2.6.37
>>> kernels to see whether there the problem exists, too. Another
>>> interesting point is that previously created subvolumes are
>>> not affected.
>>>
>>> Thanks, Andreas Philipp
>>>
>>> thor btrfs # btrfs subvolume create 123456789 Create subvolume
>>> './123456789' thor btrfs # touch 123456789/lsdkfj touch:
>>> cannot touch `123456789/lsdkfj': Read-only file system
>
>> This is really odd, but I can't reproduce it.
>
>> I created a btrfs filesystem on 2.6.37 kernel, and rebooted to
>> latest 2.6.38+, and tried the procedures as you did, but nothing
>> bad happend.
> While playing around I found the following three new points: - Now
> the length of the subvolume name does not matter. So even the ones
> with short names are read-only. - It also happens to a fresh newly
> created btrfs filesystem. - If I take a snapshot of an "old" (=
> writeable) subvolume this is writeable.
>
> I will now reboot into 2.6.37.4, check there, and then report
> back.

Well, this was fast. Everything works as expected on 2.6.37.4. See the
output of uname -a for the exact kernel version below.
I will now reboot into a differently configured kernel version 2.6.38
and look whether the problem is gone there.

Thanks,
Andreas Philipp

thor ~ # uname -a
Linux thor 2.6.37.4 #2 SMP Wed Mar 23 10:25:54 CET 2011 x86_64
Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJNicgcAAoJEJIcBJ3+XkgiDRwP/jVRcrc+Qwq8D3rE50MjBox0
vy8ZKna2MXO4dl6Et8td1ikL0T91eueIjvOeaU5cS8vxknG7xqGh9k89Nd74j98a
2paWOiR49vYYhcKF1EZm6oKgHri/N/1RfLWvhXJef3POprwz3/n3YZcSDsiXcAnJ
M8RnGgYFoXNGamPorp32rR5XMln9A6Uma+cUZuaL4eitvsZ+YDsYk4XKZ/8O+cql
u5xKihRNDRqQL7LCfqfL0iJxDl3AReOdXUo8sBmo2ioLNv+syJJhhJ2XRbx7r8rM
LDWOnsBE1oCq2QuM49MDxuD4JFhCmTJ6oJotaBShcU0J0S8Dlu1URucDO7P33BOK
qBFnavR3HaUR+MRor7U+LmeYvasmhj/hUa1nx5jvMEQqeTIioQmYLdllyvHGApfy
R4n1+/L91mRr56s96DC31mF7xnSC13LVLJLG+r3ktlj9/u6B+8LAISgo1uDJX681
YQ5KkI8O+5AcAT8Hu1pwdQVC+LXDPp8HIqL59pUWD2v4zyynVqSKgCSKLJ10npLF
+NZRhSb6czNSvM0UrUBXPLq1th+ErfMNn4b6RCrAPbA4T5bejvCUUlkx7FiAMmVx
rnfiyolblNMfQ+9rY9k8zzZeJfR88wx7yS2VoZlV7n68K01GMy+NDRK203TjcX36
+Y8kUmwptiXc48H6teUN
=aSSq
-END PGP SIGNATURE-

--
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: read-only subvolumes?

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 23.03.2011 10:25, Li Zefan wrote:
>> Hi all,
>>
>> When I am creating subvolumes I get this strange behavior. If I
>> create a subvolume with a name longer than 4 characters it is
>> read-only, if the name is shorter than 5 characters the subvolume
>> is writeable as expected. I think it is since I upgraded to
>> kernel version 2.6.38 (I do not create subvolumes on a regular
>> basis.). I will compile one of the latest 2.6.37 kernels to see
>> whether there the problem exists, too. Another interesting point
>> is that previously created subvolumes are not affected.
>>
>> Thanks, Andreas Philipp
>>
>> thor btrfs # btrfs subvolume create 123456789 Create subvolume
>> './123456789' thor btrfs # touch 123456789/lsdkfj touch: cannot
>> touch `123456789/lsdkfj': Read-only file system
>
> This is really odd, but I can't reproduce it.
>
> I created a btrfs filesystem on 2.6.37 kernel, and rebooted to
> latest 2.6.38+, and tried the procedures as you did, but nothing
> bad happend.
While playing around I found the following three new points:
- - Now the length of the subvolume name does not matter. So even the
ones with short names are read-only.
- - It also happens to a fresh newly created btrfs filesystem.
- - If I take a snapshot of an "old" (= writeable) subvolume this is
writeable.

I will now reboot into 2.6.37.4, check there, and then report back.

Thanks,
Andreas Philipp
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJNicZIAAoJEJIcBJ3+XkgiDysP/1oo770VqaEhf3F9gXq5/V3W
AkGGuRb0Upkwie5Y7L3YjCAjAJplYCemncsjqLDQVIQP6iYfmC3bLIM1GjDjMLfT
uwt89/pDte2JStW6kFx0u5i7IwYD6NO7vh3/i7+l1RB4qpZ7DAomroeHS5FFgD2M
y6hZcQ/bhiRKDv82c7YscBVE3ZgKIDPUHoNeduCGsCj8hSd4+/8PR7auGjv42a/l
C92G01cx4mMS0pmnwLUL4U54n1rbJNrKkaoQwINNW/E3fj6gQRwtI1QyDhDWnmfO
Y6c3JRtyYeWGadCaMq4SYGWvSFhG8jlR/a17ozubrLf/An14ywohx1pUZq0fPp9z
oxSlZCINhGBDSeahGQBw7szmU45lXf8N99TgaUTLiHyStnlQfcqpD5RyJUTSBOa2
VAVpMeuvjqw1ng+Tsd1r35e/WBtPQOd9aUj6r5Hcjt4oGlV0mL7oBAR/J0DjNYfl
kii8Ah+NWHFVw/pUVfWC3lzcwfqFIikvn3KVsR2X4LrOTmi6thrh0EG+eSOhfWuf
dI/agqONGzNGH73V7jFtWaEjetrhqRrr5Q22syqWfqX/AYbzTAlISHm574RPtf0G
P2r1fn/s/3FXGKo4zfTsscuvEE4LJaKFrjFxz5mW4wOz9hhFmTBox71ex538ZiMv
NfZzNRKpmXyZCm8USF/i
=b3lE
-END PGP SIGNATURE-

--
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

read-only subvolumes?

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Hi all,

When I am creating subvolumes I get this strange behavior. If I create
a subvolume with a name longer than 4 characters it is read-only, if
the name is shorter than 5 characters the subvolume is writeable as
expected. I think it is since I upgraded to kernel version 2.6.38 (I
do not create subvolumes on a regular basis.). I will compile one of
the latest 2.6.37 kernels to see whether there the problem exists,
too. Another interesting point is that previously created subvolumes
are not affected.

Thanks,
Andreas Philipp

thor btrfs # btrfs subvolume create 123456789
Create subvolume './123456789'
thor btrfs # touch 123456789/lsdkfj
touch: cannot touch `123456789/lsdkfj': Read-only file system

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJNia2nAAoJEJIcBJ3+XkgiTQQQAJqvn+zYbDmqmSo8ZRG86ssR
Tj0hsaAYjSWiIUxs7Y9XulmC0sZoSpvX5BLIjW1pYwECzhzrA//pQrwVbXgwbW5H
VjZ+YxcOcw4jxoUbW3lG+KYtSFMJFtbdMejmCY3GgYYIq1mtn0hBrCqZJ0syl4LO
IjyTHR/v0r7FMIgL26F1jOfC478RfhIxAgZOtd65kl7/pHOv5At+99tgM4teUoy0
I76CWu6Ls9+1XevxMWp39XNceYCtQ/WoEThuQCvPERq6Th3NWczPBTP3POSBetVA
Kcomq0TmgXQx1ZalFAFpMi9iRriDXbSm3ITSZW6Jp2BSEPurzpydchfhg0AWVNcC
Icp5b+dy2RVM/K5UNDO6lNf8p+K1wk8GGpD/Pr+K0lO0FlKX+6rApzgx54GYL3cx
0RYL+NAAwSpy1i2uBIw72gyGX/yBliX7CB+YZZ/iULk0eUd36FvpJJAJ1Isk+QNn
6WFBoRwsMrL3WfiqR5/ODO+i+z+CUzYU0mUnD9IuQkdCANyXOeQhs5AyMOPkB1NC
SS9ChpL60khwmLs9c99AyIzcvZU/q12JMvOZ2YUnfEHNIC/XmaThq11RbCIWIsl2
vjPr1QvKK+aykaOfjiTgLTwvB3mq147uEAylzIkduiQSFizMudbsI9vcO/X2pcy3
SVO9m6tlBUsCq3dU1dcA
=NEEb
-END PGP SIGNATURE-

--
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: [PATCH v2 0/2] Balance management, kernel side

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Since balancing takes a long time I liked the idea of having some
progress counter and the ability to run this long lasting task in
background with another option to cancel it if necessary. So I wanted
to give it a try. Unfortunately, all the patches did not apply on top
of kernel version 2.6.38. Is there a newer version of this patch or
died this idea in the meantime? Of course, I will test any patches.

Thanks,
Andreas Philipp


On 12.11.2010 01:36, Hugo Mills wrote:
> These two patches give a degree of control over balance
> operations. The first makes it possible to get an idea of how much
> work remains to do, by tracking the number of block groups (chunks)
> that need to be moved/rewritten. The second patch allows a running
> balance operation to be cancelled when the current block group has
> been moved.
>
> Since the last version, I've added some more locking (assigning to
> a u64 isn't atomic on non-64-bit architectures). I've not added
> the sysfs bits, as I haven't had a chance to try out Goffredo's
> sysfs code yet. I've also not implemented liubo's suggestion of
> tracking the current block group ID (I'll take that discussion up
> with him separately -- basically it's not a good fit with the
> "polling" method required by this ioctl).
>
> Hugo Mills (2): Balance progress monitoring. Cancel filesystem
> balance.
>
> fs/btrfs/ctree.h | 10  fs/btrfs/disk-io.c | 2 +
> fs/btrfs/ioctl.c | 62
>  fs/btrfs/ioctl.h
> | 8 ++ fs/btrfs/volumes.c | 66
> ++- 5 files
> changed, 146 insertions(+), 2 deletions(-)
>
> -- 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
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJNhcBJAAoJEJIcBJ3+Xkgi5usP/iUORDKVdCw6gyzZRRWIYHpj
bTn9zgvyatAtRlwdzxA17XUzx6+r3RPMZPYGSn4tMfatjghfvtPDn9RX+YFTzSAL
OM8fYWfFY36dKYLJk4N2FZ3mDC5tHsU7SCzviqyAb5qlFWVmRXuq0YFQ1TjLQ528
r77BfkbiAVXRc+t9I4BrUHueuK1IPF+XijMzvwfH6iUaX9bZ9woOs8xCqP2MCG7U
3uiTf6Hcfw3mN77hy3zlf180Dh27h47YADPMoPym3J0o/9bjbo1KcBeJ+9TYn7mv
aN5pZWSadszlAPwcfidCNGz8O5+fsIAxfBvF0BHHISIBHU8SwlBrZNx/GzyGENd9
EQduDuvi9eLm2+T9ioKcXz7KqebKs6vt4NR5wXGv7j6vLlaB+LgbH2j0oHj1ZA94
lTwd9bfJBogZCxYUlCsEMKyv/JLY/e183H0DO9pbABrqyZbK5koF0SIZxp90i1Ep
YviSBWVyzr0yERP+qenLMNG5NMXMiCup9fGBd8Upil1hTlnxDqCbpvne2MbjsLsv
CGY2w8PAnfhmGpT9L14o6ExMriHu7OhegMvBATnBv3BI9pd0ev7Titwm9pUBW/X4
0toKMUI0630gTg1klds8ibo0x5BF+0MtE29X/WFhpepxMtrR1e+IOsAy409eTb67
qpo81U/CeaaYJi+gV367
=R7Bg
-END PGP SIGNATURE-

--
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

Calculating/estimating the process of an ongoing balance

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Hi all,

During a btrfs filesystem balance there are lines like the following
one in dmesg
btrfs: relocating block group 2122280075264 flags 9
Since the "big" number is strictly decreasing, I wonder whether this
can be used as some progress counter? For example,
do I get something like a percentage of what has been done/balanced by
the following formula:
(h-l)/h
where h is the highest, i.e. first, value and l is the last, i.e.
smallest, value?

Just for interest: There are two types of these lines appearing. One
type with 'flags 9' and one with 'flags 20'. Do the first ones refer
to block groups holding metadata and the second ones to block groups
holding data or is it totally different (and more complicated)?

Thanks,
Andreas Philipp
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJNhI0qAAoJEJIcBJ3+XkgiwhEP/A/6I3y9+oNckdx0tvwHjQM2
lFJvPSv6F5jZPY3fzzgPVhq1jg/92/ixWr1S2vWAKZc1V6Jt0+DOlNbLgEBXnywD
U9nxWGvuddkb4pgXV7kvTh6a4jjhmN8Wx9oc5jvpN3ThqKcoEqnA2DUj9PcfIuhv
enF1w57RKPGWRwp21Zg88GKCFrC0/oNfEg0SImG42wm/n5QE6/AY8V8yXGim8nCD
MgjHGRxGtJ2IMTrusw9htlUrpPnZ6GNeLeShLSDipMxHTrFvg2MyQ8l6l+AKqLzo
jHVUGpFnS3pm6zK0JbEyKqOEFkVtrilc4sGbdtslv5lp+HD93mT6IcPp3FgnLApF
em1Mf1jWiXHMRpbwxJXq0n+9I3I8w3zix8fY+dmb5oGDR8tO5jz3oQxm9JWUCrXn
M8eScNE0KgydZU1/F6vP4vsc5rB3Wi6ZGCkKxcsIfdVJAdYdUBvAwLRXTc6w5kJI
goR3bswyiWb93eNJfODaUEpt3EXuZJ0hTgSANADb22TxBZqszey5mydgkY6cAa1a
7nWARcs1vdZzStmTbSp0YAkUjE8IIjAIgwuISB9/s5tYVc3TEC1Nqgiz81eqfcIE
ezdIXNsKf+6ZJFW9XbSMZ9OMSC1p4kQn+QyUvwcbmxl8iXyjM08iaw7/tj62U2ev
bZ4nen4cKMS2ACgGnwLE
=Gjkc
-END PGP SIGNATURE-

--
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: synchronous removal?

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Hi,

I came across this when I tried to build a backup server. Was there
any change on this in the meantime?

Thanks,
Andreas

On 02.08.2010 17:25, K. Richard Pixley wrote:
> How would you determine whether to remove another snapshot or to
> wait for previously removed space to be digested?
>
> If you simply remove snapshots then you'll end up removing all if
> your snapshots and df will still say you don't have enough space.
> Btdt. What I'm doing right now is removing a snapshot and
> immediately sleeping for 60 seconds in hopes that it will be
> digested in that time. Judicious use of df and log lines tell me
> that some of the space is digested in that time but I have no way,
> (that I know of), to determine whether all of it has been.
>
> --rich
>
> On Aug 2, 2010, at 4:35, Leonidas Spyropoulos 
> wrote:
>
>> I think a cron job checking the output of df could do that. The
>> shell script will check if there is enough space to create a
>> snapshot otherwise remove a snapshot.
>>
>> How about that?
>>
>> On Sun, Aug 1, 2010 at 10:11 PM, K. Richard Pixley
>>  wrote:
>>> I have an application where I want to snapshot, then do
>>> something, and based on the result, snapshot either the result
>>> or the previous state and then repeat.
>>>
>>> So far, so good. But eventually my disk fills and I want to
>>> remove the oldest snapshots, as many as I need to in order to
>>> make room enough for the next cycle.
>>>
>>> I notice that when I remove old snapshots and delete old
>>> directories, the free space on my disk, (according to df),
>>> doesn't rise immediately. But instead, I see an active
>>> btrfs_cleaner for a while and my free space rises while it
>>> runs. I'm presuming that the removed files and snapshots
>>> aren't fully reclaimed immediately but rather wait for
>>> something akin to a garbage collection much the way modern
>>> berkeley file systems do.
>>>
>>> How can I either:
>>>
>>> a) wait for the cleaner to digest the free space b) determine
>>> that the cleaner has digested all available free space for
>>> now, (if not I can sleep for a while) c) synchronously force
>>> the cleaner to digest available free space d) something else I
>>> haven't thought of yet
>>>
>>> Basically, I want to check to see if there's enough space
>>> available. If not, I want to remove some things, (including at
>>> least one snapshot), wait for the cleaner to digest, and then
>>> start over with the checking to see if there's enough space
>>> available and loop until I've removed enough things that there
>>> is enough space available. How can I do that on a btrfs file
>>> system?
>>>
>>> --rich -- 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
>>>
>>
>>
>>
>> -- Caution: breathing may be hazardous to your health. -- 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
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJNdeqeAAoJEJIcBJ3+Xkgiba8P/jb1a5K5cNuyrQTH9G3fM9X6
d1a249qdKTgr7AJkuNPQzu3xjvBJeKtFraHfMDBDQTRPmysqnUvMQmHz+dp9NmMe
mqStwhKLxxmus5B3IfGClztbhTPmkVJPVykFwcga9zYvNK3jrC+D6Y85IjLFGRBx
BCHaZIwzlDtcsDf38+/6zd7pHUtN5UR64mlvyyMQVOl+KEcAyNmDNwgvVDG3BhJK
wswF3GE1H0G69jkJb0dOLfLzdLvNyxjdLHYVGMx7GMnEMuYIEgJZsVkT1Anqmql8
gcKjE4kvyC9zz93c6gdJOyO/RVF7dcHP4uQY7FvM9kp+ubkeA08jZcctqz+B2yR8
fpomkeogg/7AUb2my4bpmqEULpSf6PgcKUshZFFAJQBmDxbfyiIDIo2oExbnN+qq
m+Kmg7CBwMTtVNUUen+Cdl3y7oleQ8d8XzzW+hSBq3KQQfGowh1bpp12FKbwbgDx
h4WvGbLF1tLXedP2puCYR6Dg0Th/WWwxBytKZjdyVSWX4XaJUePw/CLfvtNSpAt4
GbCiltIa8LSnJvlYZabwJhTtcEoeUl+Xu/03pZbiaDnFP3kMDqUBm8RMHwnpkmmo
z9tr5mBZFXYb7x2T2Idk5Oh7Ii53Q3XW0bgKf7mkxVvSb9TM+t/vnOX4mLBoVMun
qJoGA8SiN72k13Ki8F1H
=jxH9
-END PGP SIGNATURE-

--
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

Btrfs balance

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Hi,

Maybe it is a very stupid question but I want to ask it anyway. In
general, 'btrfs filesystem balance' takes very long to finish and
produces lots of IO. So what are the classical usage scenarios, when
it is (really) worth doing a balance?

Thanks,
Andreas Philipp
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJNODOKAAoJEJIcBJ3+XkgiUisP/A6PywwxIBFj9NuiQ9UAA5vY
QJRn/tXT+Ue2wqgZjhGaqD71Q36ALchSXonX9EXoHWRl0VtrX/2MKkPfEZvBXcDs
yVLOj647HgFu6e51gmdgGvx3qtLsQlFpXBtqYXU8+aeMUUicUZsY8ym+7w6L3jKl
0mKF7nRkdbF0JyBg4NqvbABtBrXEXIEz7hY0oQtFkjuu72iiAriLuKRRkiTnAck9
gkQ1aqcCLLUq7TPQsCdto6s7uSoQPQnZ1zXQ1G1Ij0jUItkU9h9bIjkAcbAjHV4n
cVVF5Zz2lk+z4eAHZwAKgyzzaYW5DT7+ZNrCDOls1CPQr0xka/giRa1dYjS2sas0
GZhPKtCljfROFsOGRs//DcFyu6P3X9WUHM7JRl3v5m0O1EyKlFKMP5O++BNEiB+I
9xUDnYqXzh64MiJBUk5WwGIJuHzZtlfq/PPznWoA2BpO/0/yODKyvd8MkXyEs3ht
3aHi9nbLBe7KqF7CrwH1epchoGKQw/iWopLJMFT6YVL+fHu3CC1aclzekdUh7ktX
ybdW+x575XixhCMrOw9xl0a2dRRIozBYWi5t56rpx8UMkwJwBmvwUOzS1ap9SZLx
c3jSiph8VR8cxtDu/NNFs46iXD/5I7EYlgin3FxD2qrYJOJAcR4d5V08CwGxM+/s
rnskJ6vWv4P71hvevI+R
=XwNW
-END PGP SIGNATURE-

--
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: Update to Project_ideas wiki page

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 17.11.2010 18:56, Hugo Mills wrote:
> On Wed, Nov 17, 2010 at 04:12:29PM +0100, Bart Noordervliet wrote:
>> Can I suggest we combine this new RAID level management with a
>> modernisation of the terminology for storage redundancy, as has been
>> discussed previously in the "Raid1 with 3 drives" thread of March this
>> year? I.e. abandon the burdened raid* terminology in favour of
>> something that makes more sense for a filesystem.
>
> Well, our current RAID modes are:
>
> * 1 Copy ("SINGLE")
> * 2 Copies ("DUP")
> * 2 Copies, different spindles ("RAID1")
> * 1 Copy, 2 Stripes ("RAID0")
> * 2 Copies, 2 Stripes [each] ("RAID10")
>
> The forthcoming RAID5/6 code will expand on that, with
>
> * 1 Copy, n Stripes + 1 Parity ("RAID5")
> * 1 Copy, n Stripes + 2 Parity ("RAID6")
>
> (I'm not certain how "n" will be selected -- it could be a config
> option, or simply selected on the basis of the number of
> spindles/devices currently in the FS).
Just one question on "small n": If one has N = 3*k >= 6 spindles, then
RAID5 with n = N/2-1 results in something like RAID50? So having an
option for "small n" might realize RAID50 given the right choice for n.
>
> We could further postulate a RAID50/RAID60 mode, which would be
>
> * 2 Copies, n Stripes + 1 Parity
> * 2 Copies, n Stripes + 2 Parity
Isn't this RAID51/RAID61 (or 15/16 unsure on how to put) and would
RAID50/RAID60 correspond to

* 2 Stripes, n Stripes + 1 Parity
* 2 Stripes, n Stripes + 2 Parity
>
> For brevity, we could collapse these names down to: 1C, 2C, 2CR,
> 1C2S, 2C2S, 1CnS1P, 1CnS2P, 2CnS1P, 2CnS2P. However, that's probably a
> bit too condensed for useful readability. I'd support some set of
> terms based on this taxonomy, though, as it's fairly extensible, and
> tells you the details of the duplication strategy in question.
>
>> Mostly this would involve a discussion about what terms would make
>> most sense, though some changes in the behaviour of btrfs redundancy
>> modes may be warranted if they make things more intuitive.
>
> Consider the above a first suggestion. :)
>
>> I could help you make these changes in your patches, or write my own
>> patches against yours, though I'm also completely new to kernel
>> development.
>
> Probably best to keep the kernel internals unchanged for this
> particular issue, as they don't make much difference to the naming,
> but patches to the userspace side of things (mkfs.btrfs and btrfs fi
> df specifically) should be fairly straightforward.
>
> Hugo.
Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJM5BuWAAoJEJIcBJ3+XkgiJVkP/i1YrexX3lxH6A02IWHfRIP/
+8qIDLfw5l6wuX0UV3B/ROngsI2HHvWmybFR5+rrcAkntG/EJn0amhYMrKZMDh7n
WrpWuBWjBiLI6tAkiE/ur9D3AGQhBW69okeGq2MCGYSIZNVUjVfWtEmF/OKj8soz
1Wk6Ymk0aNYBme7FMZwM/fRQnoRoV3qk5IrztzaZTClmcpM6ut+puPO42r5IEqmV
d441f7ta6vXfmXCaBA5otAdMsa3yQedkUd+wAS4xPZgN+CopeuSUUFeD4FH3b1wX
pyA9WtS8bb10cdnf0YOkbUVTgWhmsPzABqhZlmcA/8xMCMCx7Fg6eKAjGaBTcnP0
+rxWRmoyLRRS015IDat4bb31yeA8GQxteOOhpF9gLd9I0bF8QYTBSGOG9dVadEJU
PJ1aCA+5rePwadOh4wp6V0vH6BRCs7JcDc12K/gfCCFoHTyfk23j73+jJ2/dzH/E
aTDrprQIWdJE5Fk33XA1oLIcT2xNj/6PKv8DKTTj8n4SxfhViQkrNu1RrzVd5Ln1
BYbVnUbcDuAUR7AAFqRaMBVMIULJgvkaqeaQohFfONei4CgTm+A14ONcN/c0I3fV
ef9hBG2YV9X82yozLvZ0888q+eCb86AnOaVxWtnHNgvPKxnOu8Iu7NhSO53yYaro
i8aAoui00NJueGGKXzLt
=Wj4a
-END PGP SIGNATURE-

--
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: [PATCH v2 2/2] Cancel filesystem balance.

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 12.11.2010 10:07, Sander wrote:
> Chris Samuel wrote (ao):
>> On 12/11/10 12:33, Li Zefan wrote:
>>
>>> Is there any blocker that prevents us from canceling balance by
>>> just Ctrl+C ?
>>
>> Given that there's been at least 1 report of it taking 12 hours
>> to balance a non-trivial amount of data I suspect putting this
>> operation into the background by default and having the cancel
>> option might be a better plan.
>>
>> Thoughts ?
>
> My humble opinion: I very much like the way mdadm works, with the
> progress bar in /proc/mdstat if an array is rebuilding for
> example.
>
> Sander
Just my personal opinion: I would like the balance to happen in
background by default (with an option for foreground operation as
well) and another command/option to cancel the operation. Of course, a
progress bar (together with some estimate of the remaining time?) like
the one mdadm offers would be great.

Andreas Philipp
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJM3QhMAAoJEJIcBJ3+XkgioZoQAJ5bAD1xShKfda9oPK75x707
0AYu7C4sUSbu/3BINCv7XEv8MNBU++2FezRc/weSXjgmkhX4pXpMBhFZL6edlpot
VQ0y87rJ79HPe1NibiAmp4HOW95J2+R987mOJpIU10xU1TvpWAhpQextUKi27eg+
Z+XO/vm0oCv0+6YSqKnjpUPNd12r5zo7msanPnny5t57oFDXd6LCRjflt5FsP6mI
HKdM3R3EiBdlCyJsBpjDCZmJpUKvOFqoqn2OT/g7BHkE6XjuY0HqUysFLbNtWGIr
zhnx95W+cqgFY1YAvLwbrirtzX8MvO4R83c+klwQJPM9eL3+GkxyMrbnN3uQ4ie+
1wsgVCyyVT6QFLXnVeqo4ZvSNZh2/9S6waL1T0cFj1YAKBnDI3mCPo+S9CcIUuH4
KnOv3bqA3okAy0WUh3FuWNOc9fMX3tEPtE+b9JqDo1BmG0ZdnsGEdbJQxRe1xRFG
CwWsT1efV1tXEqrfsigxAlpMj9PY/uagwEYmhjQG1QU9/yGhXeZYfvE/cdYD5+Nj
chB2CpHISyQSLKAqwvLRF/tmkIjMRWrW2O3j3RGmkyEyrGl7eFKM0//1n1kmkGMc
SEAF3/fn61Wt/4YtA9r1py1Xe1deNhBGVuQQe2M1YMhITV0wSjIWPjmeL0eYu8n7
EsJdFOXoQIxIlkI7/lB+
=FQQ8
-END PGP SIGNATURE-

--
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

dkms build problem

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Hi,

I tried to follow this howto
https://btrfs.wiki.kernel.org/index.php/Btrfs_source_repositories#Building_latest_btrfs_against_a_recent_kernel_with_DKMS
from the btrfs wiki to build my own btrfs module using dkms  on my
gentoo running kernel version 2.6.35.7.
But when trying to build the dkms module I have run into the following
compile error; see my make.log below. If you have any suggestions on
what I should try to fix this, i.e., other kernel version(s), patches
to kernel/btrfs-unstable, other compiler version(s), and so on, I am
willing to try out everything in order to help fix this. If this is a
known error, and the decision is to not fix it, as btrfs compiles well
within the regular kernel sources from kernel.org, then I would add a
comment about that in the corresponding section of the btrfs wiki.

Kind regards,
Andreas Philipp

make.log:
DKMS make.log for btrfs-git for kernel 2.6.35.7 (x86_64)
Sun Oct 17 16:35:28 CEST 2010
make: Entering directory `/usr/src/linux-2.6.35.7'
  LD  /var/lib/dkms/btrfs/git/build/built-in.o
  CC [M]  /var/lib/dkms/btrfs/git/build/super.o
/var/lib/dkms/btrfs/git/build/super.c: In function ?btrfs_fill_super?:
/var/lib/dkms/btrfs/git/build/super.c:448: warning: assignment from
incompatible pointer type
  CC [M]  /var/lib/dkms/btrfs/git/build/ctree.o
  CC [M]  /var/lib/dkms/btrfs/git/build/extent-tree.o
/var/lib/dkms/btrfs/git/build/extent-tree.c: In function
?btrfs_issue_discard?:
/var/lib/dkms/btrfs/git/build/extent-tree.c:1699: error:
?DISCARD_FL_BARRIER? undeclared (first use in this function)
/var/lib/dkms/btrfs/git/build/extent-tree.c:1699: error: (Each
undeclared identifier is reported only once
/var/lib/dkms/btrfs/git/build/extent-tree.c:1699: error: for each
function it appears in.)
make[1]: *** [/var/lib/dkms/btrfs/git/build/extent-tree.o] Error 1
make: *** [_module_/var/lib/dkms/btrfs/git/build] Error 2
make: Leaving directory `/usr/src/linux-2.6.35.7'
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJMuwzFAAoJEJIcBJ3+Xkgims8P/1rX9HpYUyVBAD/wfzFaDqKH
Jq9GnI1bW9hXJMoo2l9CtVt1rSvuTFiTkK4bxuBXyt1A4eoSZ8M4exVZsYLH1+ef
+9BoJmXENnI4gDaga0N6wobjocBpvlBHYm+b2h6pP7AJFEKMXgrOra5khUc7wd3N
/Izr3Cewb9CQIr040PDOMoZCEV0iQOoSQf4ECOE3qcizq8VUqeCIiBLcH3cwTpxW
BD4AMCe/ArgirmhtPwHv2zn1RR6+vsen7oPT7tWLW86y7S4UeWGxJHRK1eTOaXlY
givWYxcHX9UvVcvCoBVvrOz2d9B5ZQM+XgTe5DztTh58cZApt7SJe4Z3Icrq4dpb
7BMmXcUwPbWRbc0/LhiCtq7J88pcDthmrNIyoengIwCoBVJu0AxTkm3s+wDh8zTy
4okNEfvl0n5l97X19hp77qeaK+ObnENAqgY2VI/yoNPnM/TbCRGyHyF9l6O3O8i/
C3QDb4U7ECPtjG8mpk1yQARqJ2hReRNslfhrMAK4BL/6cCwYx9MdslfgfwDqt+5o
VyB0E5g6+6SK7p3uuLpS92B4bDYT9Wt02YdXrbAFc5R61YUYGdSb+tr73L8a845f
Ups/FAblLSZ5TSgrBF8fmY5AJqWQl4suXNZCl8wMzeMBT5jv8adjR5dBEEtDLeSC
tHD1ignOphVos7+32ZRV
=4doD
-END PGP SIGNATURE-

--
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: [PATCH][btrfs progs] Update/clean up btrfs help and man page

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Hi all,

I tried the patch and found a few more things one might to
update/clean up.
Regarding the INSTALL file:
- - There are three example lines for snapshot creation while two can
show the same things.

Regarding the help of the btrfs command:
- - The line breaks in the source code for the help lines about the
btrfs scan command were different from all other commands.
- - The optional argument of the "scan" command was written in a strange
way.
- - Mixed usage of  and . I changed it to .
- - The "filesystem show" command accepts also the argument type .
- - Sometimes there were just two dots instead of three.

Regarding the btrfs command man page:
- - Changed the example for ambiguous commands since "btrfs device show"
no longer exists.
- - The optional argument of the "scan" command was written in a strange
way.
- - Mixed usage of  and . I changed it to .
- - The "filesystem show" command accepts also the argument type .
- - Sometimes there were just two dots instead of three.
- - In the summary, there was "filesystem defrag" instead of "filesystem
defragment".

My patch applies on top of the changes from Goffredo Baroncelli.

Kind Regards,
Andreas Philipp

diff --git a/INSTALL b/INSTALL
index 2c9cf1c..3840148 100644
- --- a/INSTALL
+++ b/INSTALL
@@ -35,9 +35,7 @@ btrfs: control program to create snapshots and
subvolumes:
 
 # snapshot of a subvolume
 btrfs subvolume snapshot /mnt/default /mnt/snapshot_of_default
- -btrfs subvolume snapshot /mnt/new_subvol_name \
- -/mnt/snapshot_of_new_subvol
- -btrfs subvolume snapshot /mnt/snapshot_of_new_subvol \
+btrfs subvolume snapshot /mnt/snapshot_of_default \
 /mnt/snapshot_of_a_snapshot
 
 # list of the subvolumes
diff --git a/btrfs.c b/btrfs.c
index a607786..1b1adb7 100644
- --- a/btrfs.c
+++ b/btrfs.c
@@ -84,7 +84,7 @@ static struct Command commands[] = {
 "the id of the device which grown or will shrink."
 },
 { do_show_filesystem, 999,
- -  "filesystem show", "[|]\n"
+  "filesystem show", "[||]\n"
 "Show the info of a btrfs filesystem. If no  or \n"
 "is passed, info of all the btrfs filesystem are shown."
 },
@@ -96,17 +96,17 @@ static struct Command commands[] = {
   "filesystem balance", "\n"
 "Balance the chunks across the device."
 },
- -{ do_scan,
- -  999, "device scan", "[ [..]\n"
+{ do_scan, 999,
+  "device scan", "[...]\n"
 "Scan all device for or the passed device for a btrfs\n"
 "filesystem."
 },
 { do_add_volume, -2,
- -  "device add", " [..] \n"
+  "device add", " [...] \n"
 "Add a device to a filesystem."
 },
 { do_remove_volume, -2,
- -  "device delete", " [..] \n"
+  "device delete", " [...] \n"
 "Remove a device from a filesystem."
 },
 /* coming soon
diff --git a/man/btrfs.8.in b/man/btrfs.8.in
index 1997aa8..6caee8b 100644
- --- a/man/btrfs.8.in
+++ b/man/btrfs.8.in
@@ -19,19 +19,19 @@ btrfs \- control a btrfs filesystem
 .PP
 \fBbtrfs\fP \fBfilesystem balance\fP\fI  \fP
 .PP
- -\fBbtrfs\fP \fBfilesystem defrag\fP\fI [-vcf] [-s start] [-l len] [-t
size] | [|...]\fP
+\fBbtrfs\fP \fBfilesystem defragment\fP\fI [-vcf] [-s start] [-l len]
[-t size] | [|...]\fP
 .PP
 \fBbtrfs\fP \fBfilesystem sync\fP\fI  \fP
 .PP
 \fBbtrfs\fP \fBfilesystem resize\fP\fI
[:][+/\-][gkm]|max \fP
 .PP
- -\fBbtrfs\fP \fBdevice scan\fP\fI [ [..]]\fP
+\fBbtrfs\fP \fBdevice scan\fP\fI [...]\fP
 .PP
- -\fBbtrfs\fP \fBdevice show\fP\fI | [|...]\fP
+\fBbtrfs\fP \fBdevice show\fP\fI [||]\fP
 .PP
- -\fBbtrfs\fP \fBdevice add\fP\fI  [..]  \fP
+\fBbtrfs\fP \fBdevice add\fP\fI  [...]  \fP
 .PP
- -\fBbtrfs\fP \fBdevice delete\fP\fI  [..]  \fP]
+\fBbtrfs\fP \fBdevice delete\fP\fI [...]  \fP]
 
 .PP
 \fBbtrfs\fP \fBhelp|\-\-help|\-h \fP\fI\fP
@@ -49,11 +49,11 @@ For example: it is possible to run
 instead of
 .I btrfs subvolume snapshot.
 But
- -.I btrfs dev s
+.I btrfs dev a
 is not allowed, because
- -.I dev s
+.I dev a
 may be interpreted both as
- -.I device show
+.I device add
 and as
 .I device scan.
 In this case
@@ -119,7 +119,7 @@ If the switch \fB-t\fR is passed, any extent
bigger than \fB\fR is
 considered already defragged.
 .TP
 
- -\fBdevice scan\fR \fI[ [..]]\fR
+\fBdevice scan\fR \fI[...]\fR
 Scan devices for a btrfs filesystem. If no devices are passed,
\fBbtrfs\fR scans
 all the block devices.
 .TP
@@ -154,9 +154,9 @@ partition after reducing the size of the filesystem.
 To know the ID of a device use the command \fBbtrfs filesystem show\fR.
 .TP
 
- -\fBfilesystem show\fR [|]\fR
+\fBfilesystem show\f

Re: [PATCH][btrfs progs] Update/clean up btrfs help and man page

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Hi,

Today I pulled btrfs-progs-unstable from
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git
and I found the patch from below still not applied. Is there a reason
for this?

Regards,
Andreas Philipp

On 13.09.2010 21:23, Goffredo Baroncelli wrote:
> Hi all,
>
> enclose you can find a patch which improve the help of the btrfs
> commands and its man page. Regarding the help of the btrfs
> command: - moved the "subvolume set-default" command in the
> "subvolume" commands group - removed a wrong new line
>
> Regarding the btrfs command man page: - renaming the command
> "device balance" in "filesystem balance" (thanks to Andrea Phillipp
> to highlight that) - adding the entry "subvolume find-new"
>
> Chris, you can pull the patch from the branch "help_cleanup" of the
> following repository.
>
> http://cassiopea.homelinux.net/git/btrfs-progs-unstable-all.git
>
> The patch is very simple: only update the man page and move some
> lines in the help of btrfs command. Comments are welcome.
>
> Regards G.Baroncelli
>
>
> diff --git a/btrfs.c b/btrfs.c index ab5e57f..1816597 100644 ---
> a/btrfs.c +++ b/btrfs.c @@ -61,6 +61,11 @@ static struct Command
> commands[] = { { do_subvol_list, 1, "subvolume list", "\n"
> "List the snapshot/subvolume of a filesystem." }, + {
> do_set_default_subvol, 2, + "subvolume set-default", "
> \n" + "Set the subvolume of the filesystem  which will
> be mounted\n" + "as default." + }, { do_find_newer, 2, "subvolume
> find-new", " \n" "List the recently modified files
> in a filesystem." }, @@ -68,11 +73,6 @@ static struct Command
> commands[] = { "filesystem defragment", "[-vcf] [-s start] [-l len]
> [-t size] | [|...]\n" "Defragment a file or a
> directory." }, - { do_set_default_subvol, 2, - "subvolume
> set-default", " \n" - "Set the subvolume of the
> filesystem  which will be mounted\n" - "as default." - }, {
> do_fssync, 1, "filesystem sync", "\n" "Force a sync on the
> filesystem ." @@ -89,7 +89,7 @@ static struct Command
> commands[] = { }, { do_df_filesystem, 1, "filesystem df",
> "\n" - "Show space usage information for a mount point\n." +
> "Show space usage information for a mount point." }, { do_balance,
> 1, "filesystem balance", "\n" diff --git a/man/btrfs.8.in
> b/man/btrfs.8.in index 26ef982..249426c 100644 ---
> a/man/btrfs.8.in +++ b/man/btrfs.8.in @@ -15,6 +15,10 @@ btrfs \-
> control a btrfs filesystem .PP \fBbtrfs\fP \fBsubvolume
> set-default\fP\fI  \fP .PP +\fBbtrfs\fP \fBsubvolume
> find-new\fP\fI  \fP +.PP +\fBbtrfs\fP
> \fBfilesystem balance\fP\fI  \fP +.PP \fBbtrfs\fP
> \fBfilesystem defrag\fP\fI | [|...]\fP .PP
> \fBbtrfs\fP \fBfilesystem sync\fP\fI  \fP @@ -25,8 +29,6 @@
> btrfs \- control a btrfs filesystem .PP \fBbtrfs\fP \fBdevice
> show\fP\fI | [|...]\fP .PP -\fBbtrfs\fP
> \fBdevice balance\fP\fI  \fP -.PP \fBbtrfs\fP \fBdevice
> add\fP\fI  [..]  \fP .PP \fBbtrfs\fP \fBdevice
> delete\fP\fI  [..]  \fP] @@ -102,6 +104,10 @@ Set
> the subvolume of the filesystem \fI\fR which is mounted as is
> returned by the \fBsubvolume list\fR command. .TP
>
> +\fBsubvolume find-new\fR\fI  \fR +List the
> recently modified files in a subvolume, after \fI\fR ID.
> +.TP + \fBfilesystem defragment\fP\fI |
> [|...]\fR Defragment files and/or directories. .TP @@
> -143,7 +149,7 @@ Show the btrfs filesystem with some additional
> info. If no UUID or label is passed, \fBbtrfs\fR show info of all
> the btrfs filesystem. .TP
>
> -\fBdevice balance\fR \fI\fR +\fBfilesystem balance\fR
> \fI\fR Balance the chunks of the filesystem identified by
> \fI\fR across the devices. .TP
>
>
>
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJMsHIyAAoJEJIcBJ3+XkgiF5kQAIg4h4g6Nbo41zFo1VRxFmbA
Ba2894xl+UOQ1u+4w3D0mIzqRq55aJ0XsC1s7hMXAPO73N18epmG//I/im29h0Pj
0tOKWlVaGq+2k9zNp2nvdnD4/FCTjdrLngRVj/QRbfnADHPqMz2vXRl1pPUNY19E
Z/WHKwRmgz/ZX1xeT2A2633sR61yYjA09XOS6Zmnh4PL6KRFZzVoDo6ciOtmdJRD
faHkLbLsxkpyA/0KPAOibDSV/uRRCMqJlBmGhbv8/QIYRvRpSiTuxT6a5B+WuFLm
1nfUsZC/NupDA1iG7T3o8gPnXCClh2Z689qq/MRHXM9N9uRhY4XDaf2GzwDMCL6q
A6ciYc1SQBHR9t/ZbUbZda8/6DAviqxIjTg4+/2G9hD8EZEqxd27B27U3Jc4AJTa
HYRxvZIeZBwrGj68RAJadU6OnkgMLvPhZ+lIODEZmEeSKlyrQQOE4gIT5YELw2+J
xz51nmfgSgMpccb8vo1edZcqA8jAuO3oJPL2h9NT78D0tCYjJWzp57HTCV8v2mBR
+fmxl0fiE82NBnCbQXeqnDkAkJPAvWBIGplCk3ScoerPFeW70QbiaQiSyrH8iOaI
9GIJFT5vt9FNyclp734nWvC9AdojS4w+lGoqIVoIehpcQfBbVa4abr2BjSvTmz/h
gzep5nPQpPH7i7btDaw1
=zs3e
-END PGP SIGNATURE-

--
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: Francis Galiegue would like your help testing a survey

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 28.09.2010 21:00, Francis Galiegue wrote:
> On Tue, Sep 28, 2010 at 16:27, Francis Galiegue 
wrote:
>> Here is a preview of the survey.
>>
>> I have not included *all* feature requests yet, otherwise it wouldn't
fit on a screen :), but I think I have chosen the most important ones.
>>
>> Please comment!
>>
>> Click on the following link to test this survey:
>>
http://appv3.sgizmo.com/testsurvey/survey?id=376617&crc=98980edfce58a795c966488276754ddb
>
> Updated with the feedback I have had so far.
In the question about the features one is using day by day on the last
page "Multiple device (RAID)" is listed twice.
Everything else looks really nice.

Kind Regards,
Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJMoj+bAAoJEJIcBJ3+XkgijgwP/39iMlsHHLEMUfWOA9onXLG4
X9rSZdIo7OwtIbV77yO3dwz7aV/U77Bb//fSizD5H5nfuydKI4HFAY4CK7vAuENU
qmjx7pJUVGprMHOdKXmP7vrlQ3glroI1l6mCmRec5n++1vrmV8ApVG4meZ3blqUe
RCuZePf3+mRxRBthevprFMncTUJJj10j4jCHjbYTLrhs5caNC1FMbkeTTHGQZEu/
xKvtbwwH66rBb6VvDH5BSJI2mt9P9bBjHt2YLy/BAbr10LSgerGsAVna7YQr804k
MI8SJVPkHqgXny6JHmYHnh4B3+C5vCNj+XlSSQyaXp8pGcNBrfr20mtb9UmWkArF
7j7fsqmDlBe5GEULNR+Vfzgv7iPEjEYiHkSM0Qmp2mSWFidGDZHU1jzIRL9ff6j+
Y3YQKOONe2hYrVxA0NlYXrQiFvWQsf2HXq7CMc6qvW21ssMNjUY8yq6iPl3JrsvJ
Vu4bB+TWtHQMuUqPZWh2OVhvts6O02F0Crho7/n0X08n9A0nRLs/vvh/wplNbp+X
ND7dAGAZpMOycpG7xDWpxRoGYe6DpsrrYOfuNK0uaXB6EyH90y+SyIuBsnZXJaLl
0vlgpfmdxsBheYO/MpvWi+mBHOpHZroybyVm7VaU4IiEwUuDyqsjyLOcewbKzzD8
gYinkC6tv1Be9aoVDYAe
=CDfI
-END PGP SIGNATURE-

--
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

btrfs-progs: error in manage

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Hi,

On the man page for the btrfs command balance is listed as a
subcommand under device instead of file system.

Kind Regards,
Andreas

diff --git a/man/btrfs.8.in b/man/btrfs.8.in
index 26ef982..bd73dc0 100644
- --- a/man/btrfs.8.in
+++ b/man/btrfs.8.in
@@ -21,12 +21,12 @@ btrfs \- control a btrfs filesystem
 .PP
 \fBbtrfs\fP \fBfilesystem resize\fP\fI [+/\-][gkm]|max
\fP
 .PP
+\fBbtrfs\fP \fBfilesystem balance\fP\fI  \fP
+.PP
 \fBbtrfs\fP \fBdevice scan\fP\fI [ [..]]\fP
 .PP
 \fBbtrfs\fP \fBdevice show\fP\fI | [|...]\fP
 .PP
- -\fBbtrfs\fP \fBdevice balance\fP\fI  \fP
- -.PP
 \fBbtrfs\fP \fBdevice add\fP\fI  [..]  \fP
 .PP
 \fBbtrfs\fP \fBdevice delete\fP\fI  [..]  \fP]
@@ -143,7 +143,7 @@ Show the btrfs filesystem with some additional
info. If no UUID or label is
 passed, \fBbtrfs\fR show info of all the btrfs filesystem.
 .TP

- -\fBdevice balance\fR \fI\fR
+\fBfilesystem balance\fR \fI\fR
 Balance the chunks of the filesystem identified by \fI\fR
 across the devices.
 .TP
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJMeqkcAAoJEJIcBJ3+XkgiRmcP/1RlZw+aJeVwAdhXzrYpoEY5
g7YFjH+o8RnC8sXnb35lDQq/uQ0Kk5VWkNOfhN+G9ZCMcEkA9uRP7rgUTc9OjRmL
0rTOytD/PsPCV8nhy5vJ5krO8lzQA9ChX3BOwmVXumfdl1SMSPjaw/Cp/AK3IP3K
6fCTefT7A5tOSFvTa5b4AdNj+mIn60MwF7d8on0J7OJgzhdw4ZIoQNApJ3hnldYE
kUAbfthO4jlvibEWG+wk5FEeGxkTKthZK5y/4R5PdnutWwY9f0XG5WQsJuPS7qB6
Tzz+EtxRSmTwsDJxt8RKr4k8NH+UOlZQg9VcNvdTAJaP6wkrZi39uRL7zH6bIjfh
9D+Fty2zzvMsXVORrdfL35wHKcx1xH491msn5U925ej9OU9j/tV/rYr/wSDMG3AW
GILKKzuT+9Xsgs5cYpG2ENdIeDI1kEoa/ZdYIyxSSEuo9DXb8+BsOces2kr+a1Fl
NSPIm7vQaIxcY09H9sexyEWz1IC2GnKLbMz8AuOkbNEpxbIYcuPgTdnPZrRY7xbW
K//hf3uDxkxxQ44/24hgK9o9DkVDS37nzHN7mtoGTyvDg1o4RksnFwQGZluAfShi
vfBulYqGkH50HWO25t66XholaQ1WSs4MuUb47/wNO5AocbeAezJB3WvZ+I9zLkWS
kZxFmJKvHkHwj34FxxXb
=OxAs
-END PGP SIGNATURE-

--
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: machine gets unresponsive during btrfs balance

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 26.08.2010 18:38, Johannes Hirte wrote:
> On Thursday 26 August 2010 15:39:25 Andreas Philipp wrote:
>> On 26.08.2010 15:27, Johannes Hirte wrote:
>>> Looks like another manifestation of the csum bug. Are you able
>>> to read all files from the affected volume? Did you tried a
>>> balance with an 2.6.34 kernel after the test with 2.6.35?
>>>
>> Till now I did not see any unreadable files but I did not do a
>> complete test. No, I did not try to balance with an 2.6.34
>> kernel. If it helps I can switch back and try.
>
> I hope it helps to localize the error. It's still not clear where
> this starts an what kernels are affected.
>
Unfortunately, I cannot reboot at until next Monday. But in the
meantime, I do a "test read" of all files on the volume to see whether
something cannot be read, too.

Regards,
Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJMemYyAAoJEJIcBJ3+XkgiEOgQALeGqTtd8SxZr+GgqLvWusMu
sdwszFOi/4azNZ848DAt8Xs47X/6c0K+I2ZfzQqXTGJFlGCviKa4JDxQeQf9Fy6A
q9aayLMOKqBMVTPSjIIR/y/GO6YT3M62jhnehT1wGO27JJWZzrL8xsXVpJxzJflI
V67pMbPT1FJLGKmFpJbB2AIPUuNNaSwaG9170rTlD5fCpwSE4mzzeHJK21ihG5p6
4YdGGW+ak6iB86RkYPZU69XlKOgzb1opHDcGE6rSGRncj6fdyNXhmEUiiM/RNzs8
9yFQ8TspGGnmiszrpqZ6K6b2ajEpqxtGPbOj87Xc6dRfo5/ByrXhpdHpd70gfTRZ
oMcqcyt/wfIMXonOKrkJi+Zqb2K2SzellNQ2rMpDzdJK48J7tNTw/wfoZ+l44zNm
vtCWQa04KBfhkIgqEf8GHpq4RwIaDJ4twW2TjWZNLFCTa7i1HDgmyY5K34pYmAXT
ToOgOq4b6WnnEBC0+5Fm5AYm8eknwUtRxSvH1MZyGAHQndw+38EoXgP5fe8JOsqL
VVHP1eaXBS06eSrhSYmj10bvmnn6rOBG7LxJLYlsFvrHdx/TgxMxcMDMBtWM5vsk
Lmlo0RizVlMjlsGINSKXSouv/y9h6Pyp5CVc4Xw9ByGGGkBX3bH8mI8TKdKey5y7
jUsZn1LtF3rYTBIgET5N
=8PvR
-END PGP SIGNATURE-

--
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: machine gets unresponsive during btrfs balance

[Andreas Philipp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 26.08.2010 15:27, Johannes Hirte wrote:
> On Saturday 14 August 2010 00:11:55 Andreas Philipp wrote:
>> On 12.08.2010 10:04, Yan, Zheng wrote:
>>> On Thu, Aug 12, 2010 at 3:14 PM, Andreas Philipp
>>>  wrote:
>>>   
>>>> Hi,
>>>>
>>>> I am using a btrfs filesystem created with raid0 for data and metadata
>>>> for (temporary) storage of tv recordings from my vdr. The filesystem was
>>>> created under kernel version 2.6.34. An initial btrfs balance command
>>>> succeeded. Since I upgraded to 2.6.35-rcX and 2.6.35 btrfs balance no
>>>> longer finishes but puts the machine in some unresponsive state.
>>>> Unfortunately, I do not see any kernel oops or other debug information
>>>> because even the display freezes. The last thing that happens are that
>>>> those two lines are written to /var/log/messages:
>>>> Aug 11 21:42:23 thor kernel: btrfs: found 62911 extents
>>>> Aug 11 21:42:24 thor kernel: btrfs: relocating block group 1723913469952
>>>> flags 9
>>>> After that the machine becomes immediately unresponsive.
>>>>
>>>> As I did not see anything that might be related to my problem in the
>>>> changelog for 2.6.35.1 I did not try again with this version.
>>>>
>>>> 
>>> Do you have more than one machines? would you please setup netconsole
>>> to see what happen.
>>>   
>> I have reproduced the error on v2.6.35.1 and recorded all kernel output
>> with netconsole. The interesting point is that this time the machine did
>> not crash but the btrfs balance segfaulted at exact the same position
>> where the previous crashes had happened.
> 
> Looks like another manifestation of the csum bug. Are you able to read all 
> files from the affected volume? Did you tried a balance with an 2.6.34 kernel 
> after the test with 2.6.35?
> 
Till now I did not see any unreadable files but I did not do a
complete test. No, I did not try to balance with an 2.6.34 kernel. If
it helps I can switch back and try.

Yours,
Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMdm6MAAoJEJIcBJ3+Xkgi9vUQALX7V6fOs+DJR9NGRr21uY1a
/tFj5e1r71Mryn6uFcnb2Iukf6oNirxc3n4XcSgfel/GppTPAt+s8a3jS048SNa1
XpPhpuA5j9vtPns46ZR5Bg9rTtAIa7oDO8Ko2lewnHcrZN9qoGyroTz+eIzqv/U/
N8BmGTKTE1TwKfETE8jVXXHvsQuV6vYeOJqtWzPkETw9gldHThTSvr3pl7+46yFT
iCv5n/IHsdAyeZpSJm1Jp3xxAGZJsrkhoKiyNcHHt7+UshcKpFYky4lOCAlDgpPO
quZhEHiYKUeHGYb8vueaebCgy2panrYcnEgwoGkI7XLPvTlWY/5uUgV/54rlUdwi
jqo+zgyNaBnEwUkqTAPzqZQBYb7XA5uJS7UchFhf5rpgFZeEX+gUnNYtEtUkkYLk
9vAAeXl8OyNJnBAH97/FBpRw0nVYpXeuE8/dvc1TfbHDjkOQLlgEYg3T4PW+NgsV
IwVOChoFPEmyFndAvONphTmUQjzGMJu2Y+3p9D7ZDRQOo8AHjGrErWPY+zGkZkd1
MtFCIKeTyOoR+13U4xAxi+2alGf7UE0jdxoGMQPnh7COjOYpUgMt1zFnksxn6yY+
RcFEWJSoBkOPMePxzJUTOCVb/Qr4V6HCJNEylBxF1VsECAOkjTSxl4XTAXrLKYVu
pllFS2PYozhZMoKrDKQE
=ldPn
-END PGP SIGNATURE-
--
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: [RFC] Move all btrfs command to only one command

[Andreas Philipp]

 On 20.08.2010 20:49, Josh Berry wrote:

On Fri, Aug 20, 2010 at 11:34, Andreas Philipp
  wrote:

  On 20.08.2010 20:27, Josh Berry wrote:

On Fri, Aug 20, 2010 at 05:03, Goffredo Baroncelli
  wrote:

On Thursday, 19 August, 2010, James Smith wrote:

This patch randomizes the error codes and also fixes up some typos

including

capitalization in the output.

It would almost be nice to see a translation effort for the tool as
well.

[...]

+   fprintf(stderr, "ERR-A.11: in command '");

I am not against this kind of error codes, but I prefer

+   fprintf(stderr, "Error 'ERR-A.11' in command '");

As a layman/end user, I disagree.  The former format is easier for
shell scripts and the like to parse -- the error code can be extracted
with a simple "cut -d: -f1".

This makes no difference. A simple `cut -d " " -f1` would do the job in the
second case.

I think you meant -f2, and that still leaves the quotes hanging
around.  So you'd need to cut -d" " -f2 |tr -d "'" .  It's not a big
deal either way, I just think the former is easier to work with.

Sorry, of course -f2. But why not simply cut -d "'" -f 2?
Andreas
--
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: [RFC] Move all btrfs command to only one command

[Andreas Philipp]

 On 20.08.2010 20:27, Josh Berry wrote:

On Fri, Aug 20, 2010 at 05:03, Goffredo Baroncelli  wrote:

On Thursday, 19 August, 2010, James Smith wrote:

This patch randomizes the error codes and also fixes up some typos

including

capitalization in the output.

It would almost be nice to see a translation effort for the tool as well.

[...]

+   fprintf(stderr, "ERR-A.11: in command '");

I am not against this kind of error codes, but I prefer

+   fprintf(stderr, "Error 'ERR-A.11' in command '");

As a layman/end user, I disagree.  The former format is easier for
shell scripts and the like to parse -- the error code can be extracted
with a simple "cut -d: -f1".
This makes no difference. A simple `cut -d " " -f1` would do the job in 
the second case.

Andreas

(In fact, I wish the output from things like "btrfs filesystem df",
"show", etc. were easier to parse, but that's a separate issue. :) )

-- Josh
--
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: machine gets unresponsive during btrfs balance

[Andreas Philipp]

On 12.08.2010 10:04, Yan, Zheng wrote:
> On Thu, Aug 12, 2010 at 3:14 PM, Andreas Philipp
>  wrote:
>   
>> Hi,
>>
>> I am using a btrfs filesystem created with raid0 for data and metadata
>> for (temporary) storage of tv recordings from my vdr. The filesystem was
>> created under kernel version 2.6.34. An initial btrfs balance command
>> succeeded. Since I upgraded to 2.6.35-rcX and 2.6.35 btrfs balance no
>> longer finishes but puts the machine in some unresponsive state.
>> Unfortunately, I do not see any kernel oops or other debug information
>> because even the display freezes. The last thing that happens are that
>> those two lines are written to /var/log/messages:
>> Aug 11 21:42:23 thor kernel: btrfs: found 62911 extents
>> Aug 11 21:42:24 thor kernel: btrfs: relocating block group 1723913469952
>> flags 9
>> After that the machine becomes immediately unresponsive.
>>
>> As I did not see anything that might be related to my problem in the
>> changelog for 2.6.35.1 I did not try again with this version.
>>
>> 
> Do you have more than one machines? would you please setup netconsole
> to see what happen.
>   
I have reproduced the error on v2.6.35.1 and recorded all kernel output
with netconsole. The interesting point is that this time the machine did
not crash but the btrfs balance segfaulted at exact the same position
where the previous crashes had happened.

Yours,
Andreas


netconsole.log.gz
Description: application/gzip

Re: machine gets unresponsive during btrfs balance

[Andreas Philipp]

On 12.08.2010 10:04, Yan, Zheng wrote:
> On Thu, Aug 12, 2010 at 3:14 PM, Andreas Philipp
>  wrote:
>   
>> Hi,
>>
>> I am using a btrfs filesystem created with raid0 for data and metadata
>> for (temporary) storage of tv recordings from my vdr. The filesystem was
>> created under kernel version 2.6.34. An initial btrfs balance command
>> succeeded. Since I upgraded to 2.6.35-rcX and 2.6.35 btrfs balance no
>> longer finishes but puts the machine in some unresponsive state.
>> Unfortunately, I do not see any kernel oops or other debug information
>> because even the display freezes. The last thing that happens are that
>> those two lines are written to /var/log/messages:
>> Aug 11 21:42:23 thor kernel: btrfs: found 62911 extents
>> Aug 11 21:42:24 thor kernel: btrfs: relocating block group 1723913469952
>> flags 9
>> After that the machine becomes immediately unresponsive.
>>
>> As I did not see anything that might be related to my problem in the
>> changelog for 2.6.35.1 I did not try again with this version.
>>
>> 
> Do you have more than one machines? would you please setup netconsole
> to see what happen.
>   
Sorry for not responding earlier but I did not find time before this
morning. After I have set up netconsole I am running btrfs balance at
the moment - now on 2.6.35.1.

Yours,
Andreas
--
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

machine gets unresponsive during btrfs balance

[Andreas Philipp]

Hi,

I am using a btrfs filesystem created with raid0 for data and metadata
for (temporary) storage of tv recordings from my vdr. The filesystem was
created under kernel version 2.6.34. An initial btrfs balance command
succeeded. Since I upgraded to 2.6.35-rcX and 2.6.35 btrfs balance no
longer finishes but puts the machine in some unresponsive state.
Unfortunately, I do not see any kernel oops or other debug information
because even the display freezes. The last thing that happens are that
those two lines are written to /var/log/messages:
Aug 11 21:42:23 thor kernel: btrfs: found 62911 extents
Aug 11 21:42:24 thor kernel: btrfs: relocating block group 1723913469952
flags 9
After that the machine becomes immediately unresponsive.

As I did not see anything that might be related to my problem in the
changelog for 2.6.35.1 I did not try again with this version.

Thanks,
Andreas

--
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

dkms build error

[Andreas Philipp]

Hi,

Unfortunately, I did not succeed to compile a btrfs module via dkms from
btrfs-unstable (commit 9aeead73782c4b8e2a91def36dbf95db28605c95) for kernel
version 2.6.34-git16. For the exact error message, please see the make.log
attached. If I replace the symlink to btrfs-unstable/fs/btrfs by a sumlink
to the corresponding subdirectory of the kernel tree everything works well.

Thanks,
Andreas Philipp

a...@thor ~ $ cat /var/lib/dkms/btrfs/git/build/make.log
DKMS make.log for btrfs-git for kernel 2.6.34-git16 (x86_64)
Sun May 30 20:37:43 CEST 2010
make: Entering directory `/usr/src/linux-2.6.34-git16'
  LD  /var/lib/dkms/btrfs/git/build/built-in.o
  CC [M]  /var/lib/dkms/btrfs/git/build/super.o
/var/lib/dkms/btrfs/git/build/super.c: In function ‘btrfs_fill_super’:
/var/lib/dkms/btrfs/git/build/super.c:446: warning: assignment from 
incompatible pointer type
  CC [M]  /var/lib/dkms/btrfs/git/build/ctree.o
  CC [M]  /var/lib/dkms/btrfs/git/build/extent-tree.o
/var/lib/dkms/btrfs/git/build/extent-tree.c: In function ‘btrfs_issue_discard’:
/var/lib/dkms/btrfs/git/build/extent-tree.c:1699: error: ‘DISCARD_FL_BARRIER’ 
undeclared (first use in this function)
/var/lib/dkms/btrfs/git/build/extent-tree.c:1699: error: (Each undeclared 
identifier is reported only once
/var/lib/dkms/btrfs/git/build/extent-tree.c:1699: error: for each function it 
appears in.)
make[1]: *** [/var/lib/dkms/btrfs/git/build/extent-tree.o] Error 1
make: *** [_module_/var/lib/dkms/btrfs/git/build] Error 2
make: Leaving directory `/usr/src/linux-2.6.34-git16'


--
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

help message of btrfsctl does not tell anything about deletion of a subvolume

[Andreas Philipp]

Hi,

The help message of the btrfsctl command does not tell anything about
the deletion of a subvolume. See patch below.

Kind regards,
Andreas

diff --git a/btrfsctl.c b/btrfsctl.c
index be6bf25..3ed6f2d 100644
--- a/btrfsctl.c
+++ b/btrfsctl.c
@@ -56,7 +56,7 @@ static void print_usage(void)
 printf("\t-A device: scans the device file for a Btrfs filesystem\n");
 printf("\t-a: scans all devices for Btrfs filesystems\n");
 printf("\t-c: forces a single FS sync\n");
-printf("\t-D: delete snapshot\n");
+printf("\t-D: delete snapshot or subvolume\n");
 printf("\t-m [tree id] directory: set the default mounted subvolume"
" to the [tree id] or the directory\n");
 printf("%s\n", BTRFS_BUILD_VERSION);

--
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

add subvolume when / is not mounted?

[Andreas Philipp]

Hi,

Well, I do not know if here is the right place to ask questions like
this one so please tell me if it is not.
The situation is the following: btrfs (data and metadata single) on
/dev/sda3 (size 100GB) with two subvolumes /one and /two. Both
subvolumes are mounted to /mnt/one resp. /mnt/two. Is there a way to
create a third subvolume, say three outside of the two existing
subvolumes without mounting "the whole volume /dev/sda3" or even worse
unmounting the two subvolumes before?

Thanks,
Andreas
--
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: [PATCH 0/2 V2] btrfs: a new tool to manage a btrfs filesystem

[Andreas Philipp]

Hi,

Cool tool.
Just looking at the help output on the console I found a small typo.

Kind regards,
Andreas Philipp

diff --git a/btrfs.c b/btrfs.c
index cc55599..f3e5d8d 100644
--- a/btrfs.c
+++ b/btrfs.c
@@ -633,7 +633,7 @@ static struct Command commands[] = {
"Add a device to a filesystem"
},
{ -1, "rm-dev", "-R", " [..] \n"
-   "Remove a device to a filesystem"
+   "Remove a device from a filesystem"
},
/* coming soon
{ 2, "label", "-m", " \n"


On 17.02.2010 21:02, Goffredo Baroncelli wrote:
> Hi all,
>
> enclosed in the next two emails you can find two patches which introduce a 
> new 
> program called "btrfs". This program has the ambitious to replace the 
> utilities of the btrfs-prog package, like:
> - btrfsctl
> - btrfs-show
> - btrfs-volume
> - btrfs
>
> The goals are:
> - improve the usability of the tools 
> - add a man page which documents all the commands
> - correct the btrfsctl return codes
>
> I put a lot of attentions in order to avoid regression respect the old tools.
> A clone of my git repository is available at
>
> http://cassiopea.homelinux.net/git/btrfs-command.git
>
> On the basis of the feedback of the previous patches I rearranged some "short 
> command name" (-s, -c ...) in order to avoid collision. I renamed also the 
> command "create" in "subvolume" (and the relative short command name from 
> '-S' 
> to '-c' :-) ).
>
> Chris, do you think that these patches are mergeable ?
>
> Comments are welcome.
>
> BR
> Goffredo
> ---
>
>  Makefile   |5
>  btrfs.c|  775 +
>  man/Makefile   |5
>  man/btrfs.8.in |  122 
>  4 files changed, 905 insertions(+), 2 deletions(-)
>
> --
>
> Example of use:
> $ btrfs
> Usage:
> btrfs snapshot|-s [/]
> Create a writeble snapshot of the subvolume  with
> the name  in the  directory.
> btrfs delete|-D 
> Delete the subvolume .
> btrfs subvolume|-c [/]
> Create a subvolume in  (or the current directory if
> not passed).
> btrfs defrag|-f | [|...]
> Defragment a file or a directory.
> btrfs scan|-n [ [..]
> Scan all device for or the passed device for a btrfs
> filesystem.
> btrfs fssync|-y 
> Force a fs sync on the filesystem 
> btrfs resize|-z [+/-][gkm]|max 
> Resize the file system. If 'max' is passed, the filesystem
> will occupe all available space on the device.
> btrfs show|-l [|...]
> Show the btrfs devices
> btrfs balance|-b 
> Balance the chunk across the device
> btrfs add-dev|-A  [..] 
> Add a device to a filesystem
> btrfs rm-dev|-R  [..] 
> Remove a device to a filesystem
>
> btrfs help|--help|-h
> Show the help.
>
> Btrfs v0.19-12-g7e4c8e8-dirty
>
>
>
>
> BTRFS(8) btrfsBTRFS(8)
>
>
>
> NAME
>btrfs - control a btrfs filesystem
>
> SYNOPSIS
>btrfs  snapshot|-s   [/]
>
>btrfs  delete|-D  
>
>btrfs  subvolume|-c  [/]
>
>btrfs  defrag|-f  | [|...]
>
>btrfs  fssync|-y  
>
>btrfs  resize|-z  [+/-][gkm]|max 
>
>btrfs  scan|-n  [ [..]]
>
>btrfs  show|-l  | [|...]
>
>btrfs  balance|-b  
>
>btrfs  add-dev|-A   [..] 
>
>btrfs  rm-dev|-R   [..]  ]
>
>
>btrfs  help|--help|-h
>
> DESCRIPTION
>btrfs  is  used to control the filesystem and the files and directories
>stored. It is the tool to create or destroy a new  snapshot  or  a  new
>subvolume for the filesystem, to defrag a file or a directory, to flush
>the dato to the disk, to resize the filesystem, to scan the device.
>
>
> OPTIONS
>snapshot|-s  [/]
>   Create a writeble snapshot of the subvolumewith  the
>   namein the  directory. If  is not a sub‐
>   volume, btrfs returns an error. 
>
>
>delete|-D 
>   Delete the subvolume . If  is not  a  sub‐
>   volume, btrfs returns an error. 
>
>
>