Re: Btrfs balance invalid argument error

2013-05-11 Thread 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 re...@yerf-it.nl

 On May 10, 2013, at 10:21 PM, Hugo Mills h...@carfax.org.uk 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 RESEND 0/2] Two small patches for the raid56 code

2013-05-11 Thread 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


[PATCH RESEND 1/2] Minor format cleanup.

2013-05-11 Thread Andreas Philipp
Clean up the format of the definitions of BTRFS_BLOCK_GROUP_RAID5 and
BTRFS_BLOCK_GROUP_RAID6.

Signed-off-by: Andreas Philipp philipp.andr...@gmail.com
---
 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 2/2] Correct allowed raid levels on balance.

2013-05-11 Thread 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 philipp.andr...@gmail.com
---
 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 0/2] Two small patches for the raid56 code

2013-02-13 Thread 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

2012-10-22 Thread 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

2012-09-10 Thread 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


Re: Cannot create subvolume with quota enabled

2012-09-10 Thread Andreas Philipp
2012/9/10 Arne Jansen sensi...@gmx.net:
 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


Cannot create subvolume with quota enabled

2012-09-07 Thread 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

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

2012-07-28 Thread 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: btrfs_print_tree?

2012-07-01 Thread 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
 mike.fleetw...@googlemail.com wrote:
 On 1 July 2012 05:53, Zhi Yong Wu zwu.ker...@gmail.com 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: btrfs_print_tree?

2012-07-01 Thread 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
 mike.fleetw...@googlemail.com wrote:
 On 1 July 2012 05:53, Zhi Yong Wu zwu.ker...@gmail.com 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: Can't write much data on a degraded mirror

2012-03-10 Thread 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 V2] Btrfs-progs: add btrfs subvolume get-default subcommand

2011-07-11 Thread 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 yi.y.y...@intel.com
 Signed-off-by: Zhong, Xin xin.zh...@intel.com
 ---
 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 path which will be mounted\n
 as default.
 },
 + { do_get_default_subvol, 1, subvolume get-default, path\n
 + Get the default subvolume of a filesystem.
 + },
 { do_fssync, 1,
 filesystem sync, path\n
 Force a sync on the filesystem path.
 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;
 + char *subvol;
 +
 + subvol = argv[1];
 +
 + ret = test_issubvolume(subvol);
 + if (ret  0) {
 + fprintf(stderr, ERROR: error accessing '%s'\n, subvol);
 + return 12;
 + }
 + if (!ret) {
 + fprintf(stderr, ERROR: '%s' is not a subvolume\n, subvol);
 + return 13;
 + }
 +
 + fd = open_file_or_dir(subvol);
 + if (fd  0) {
 + fprintf(stderr, ERROR: can't access '%s'\n, subvol);
 + return 12;
 + }
 + ret = list_subvols(fd, 1);
 + if (ret)
 + return 19;
 + return 0;
 +}
 +
 int do_df_filesystem(int nargs, char **argv)
 {
 struct btrfs_ioctl_space_args *sargs;
 diff --git a/btrfs_cmds.h b/btrfs_cmds.h
 index 7bde191..9cf1ca1 100644
 --- a/btrfs_cmds.h
 +++ b/btrfs_cmds.h
 @@ -28,7 +28,8 @@ int do_scan(int nargs, char **argv);
 int do_resize(int nargs, char **argv);
 int do_subvol_list

Re: How to get the default subvolume?

2011-07-08 Thread 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?

2011-07-06 Thread 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


Re: [PATCH 2/3] add btrfs-list.o as a seperate target

2011-07-03 Thread 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 philipp.andr...@gmail.com
 ---
 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


[PATCH] remove unused include version.h

2011-07-03 Thread Andreas Philipp
In the file btrfs-list.c version.h was included but not used. So just
drop it.

Signed-off-by: Andreas Philipp philipp.andr...@gmail.com
---
 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


[PATCH v2] print parent ID in btrfs suvolume list

2011-07-01 Thread 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 philipp.andr...@gmail.com
- ---
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, path\n
+   { do_subvol_list, -1, subvolume list, [-p] path\n
List the snapshot/subvolume of a filesystem.,
- -   NULL
+   [-p] path\n
+   List the snapshot/subvolume of a filesystem.\n
+   -pprint parent ID
},
{ do_set_default_subvol, 2,
  subvolume set-default, id path\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 do_resize(int nargs, char **argv);
 int do_subvol_list(int nargs, char **argv);
 int do_set_default_subvol(int nargs, char **argv);
- -int list_subvols(int fd);
+int list_subvols(int fd, int print_parent);
 int do_df_filesystem(int nargs, char **argv);
 int

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

2011-07-01 Thread 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] source [dest/]name\n
 Create a writable/readonly snapshot of the subvolume source with\n
 the name name in the dest 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 source and
 name 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] source [dest/]name\n
   Create a writable/readonly snapshot of the subvolume source 
 with\n
   the name name in the dest 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


Re: btrfs-progs: integration branch updated

2011-07-01 Thread 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_buffer *? 

Re: subvolumes missing from btrfs subvolume list output

2011-06-30 Thread 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-btrfsm=129238454714319w=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: subvolumes missing from btrfs subvolume list output

2011-06-30 Thread 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-btrfsm=129238454714319w=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-btrfsm=129238454714319w=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: [PATCH] [btrfs-progs integration] incorrect argument checking for btrfs sub snap -r

2011-06-30 Thread 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] source [dest/]name\n
 Create a writable/readonly snapshot of the subvolume source with\n
 the name name in the dest 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 source and
name 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: btrfs-progs: integration branch updated

2011-06-30 Thread 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: [PATCH v6 2/8] Add --monitor option to btrfs balance progress.

2011-06-30 Thread 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 h...@carfax.org.uk --- 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, path\n Synonym for \btrfs
 filesystem balance\. }, - { do_balance_progress, 1, - balance
 progress, path\n + { do_balance_progress, -1, + balance
 progress, [-m|--monitor] path\n Show progress of the balance
 operation running on path. }, { 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
 path \fP .PP -\fBbtrfs\fP \fBbalance progress\fP\fI path\fP
 +\fBbtrfs\fP \fBbalance progress\fP [\fB-m\fP|\fB--monitor\fP]
 \fIpath\fP .PP \fBbtrfs\fP \fBdevice show\fP\fI dev|label
 [dev|label...]\fP .PP @@ -162,9 +162,10 @@ Add device(s) 

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

2011-06-30 Thread 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 h...@carfax.org.uk
 ---
  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, path\n
   Synonym for \btrfs filesystem balance\.
   },
 - { do_balance_progress, 1,
 -   balance progress, path\n
 + { do_balance_progress, -1,
 +   balance progress, [-m|--monitor] path\n
   Show progress of the balance operation running on path.
   },
   { 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 

Re: Integration branch updated

2011-06-27 Thread 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

2011-06-14 Thread 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


[PATCH] print parent ID in btrfs suvolume list

2011-06-13 Thread 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 philipp.andr...@gmail.com
---
 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


Re: strange filefrag output on btrfs

2011-06-13 Thread 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


strange filefrag output on btrfs

2011-06-11 Thread 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!

2011-06-04 Thread 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:[a11011de]  [a11011de] 
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:
 [a1101dec] ? insert_inline_extent_backref+0x63/0xec [btrfs]
 [a10fd427] ? update_block_group+0x1d4/0x1f1 [btrfs]
 [a1101f26] ? __btrfs_inc_extent_ref+0xb1/0x1e3 [btrfs]
 [a110322e] ? run_clustered_refs+0x69d/0x768 [btrfs]
 [a11033c6] ? btrfs_run_delayed_refs+0xcd/0x1c0 [btrfs]
 [a110d59f] ? __btrfs_end_transaction+0x66/0x1c1 [btrfs]
 [a1118a07] ? btrfs_finish_ordered_io+0x2b3/0x2d8 [btrfs]
 [a1128c15] ? end_bio_extent_writepage+0xa0/0x14a [btrfs]
 [a1132208] ? worker_loop+0x17f/0x47d [btrfs]
 [a1132089] ? btrfs_queue_worker+0x248/0x248 [btrfs]
 [a1132089] ? btrfs_queue_worker+0x248/0x248 [btrfs]
 [810432d8] ? kthread+0x7a/0x82
 [812e1dd4] ? kernel_thread_helper+0x4/0x10
 [8104325e] ? kthread_worker_fn+0x139/0x139
 [812e1dd0] ? gs_change+0xb/0xb
Code: 24 50 41 b9 01

Re: strange btrfs sub list output

2011-05-31 Thread 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
 stephane_chaze...@yahoo.fr 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

2011-05-27 Thread 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=subvolume,subvolrootid=top-level ID
/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


Re: strange btrfs sub list output

2011-05-27 Thread 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=subvolume,subvolrootid=top-level ID
 /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

2011-05-27 Thread 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

2011-05-27 Thread 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


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

2011-04-26 Thread 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 1/5] Added support for an additional ioctl.

2011-04-26 Thread 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 philipp.andr...@gmail.com
---
 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 5/5] Updated manpage for btrfs subvolume snapshot.

2011-04-26 Thread Andreas Philipp

Signed-off-by: Andreas Philipp philipp.andr...@gmail.com
---
 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 source [dest/]name\fP
+\fBbtrfs\fP \fBsubvolume snapshot\fP\fI [-r] source [dest/]name\fP
 .PP
 \fBbtrfs\fP \fBsubvolume delete\fP\fI subvolume\fP
 .PP
@@ -70,10 +70,11 @@ command.
 .SH COMMANDS
 .TP
 
-\fBsubvolume snapshot\fR\fI source [dest/]name\fR
-Create a writable snapshot of the subvolume \fIsource\fR with the name
-\fIname\fR in the \fIdest\fR directory. If \fIsource\fR is not a
-subvolume, \fBbtrfs\fR returns an error.
+\fBsubvolume snapshot\fR\fI [-r] source [dest/]name\fR
+Create a writable/readonly snapshot of the subvolume \fIsource\fR with the
+name \fIname\fR in the \fIdest\fR directory. If \fIsource\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 subvolume\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] Support the new parameters in do_clone(int argc, char** argv).

2011-04-26 Thread 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 philipp.andr...@gmail.com
---
 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, source [dest/]name\n
-   Create a writable snapshot of the subvolume source with\n
+   { do_clone, -2,
+ subvolume snapshot, [-r] source [dest/]name\n
+   Create a writable/readonly snapshot of the subvolume source 
with\n
the name name in the dest 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 2/5] Add support for read-only subvolumes.

2011-04-26 Thread 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 philipp.andr...@gmail.com
---
 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(res0){
@@ -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.

2011-04-26 Thread Andreas Philipp

Signed-off-by: Andreas Philipp philipp.andr...@gmail.com
---
 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 1/5] Add support for read-only subvolumes.

2011-04-25 Thread 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 philipp.andr...@gmail.com
---
 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(res0){
@@ -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 2/5] Support the new parameters in do_clone(int argc, char** argv).

2011-04-25 Thread 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 philipp.andr...@gmail.com
---
 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, source [dest/]name\n
-   Create a writable snapshot of the subvolume source with\n
+   { do_clone, -2,
+ subvolume snapshot, [-r] source [dest/]name\n
+   Create a writable/readonly snapshot of the subvolume source 
with\n
the name name in the dest 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 4/5] Test the additional ioctl.

2011-04-25 Thread Andreas Philipp
Signed-off-by: Andreas Philipp philipp.andr...@gmail.com
---
 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.

2011-04-25 Thread 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 philipp.andr...@gmail.com
---
 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 5/5] Updated documentation for btrfs subvolume snapshot.

2011-04-25 Thread Andreas Philipp
Signed-off-by: Andreas Philipp philipp.andr...@gmail.com
---
 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 source [dest/]name\fP
+\fBbtrfs\fP \fBsubvolume snapshot\fP\fI [-r] source [dest/]name\fP
 .PP
 \fBbtrfs\fP \fBsubvolume delete\fP\fI subvolume\fP
 .PP
@@ -70,10 +70,11 @@ command.
 .SH COMMANDS
 .TP
 
-\fBsubvolume snapshot\fR\fI source [dest/]name\fR
-Create a writable snapshot of the subvolume \fIsource\fR with the name
-\fIname\fR in the \fIdest\fR directory. If \fIsource\fR is not a
-subvolume, \fBbtrfs\fR returns an error.
+\fBsubvolume snapshot\fR\fI [-r] source [dest/]name\fR
+Create a writable/readonly snapshot of the subvolume \fIsource\fR with the
+name \fIname\fR in the \fIdest\fR directory. If \fIsource\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 subvolume\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 2/5] Support the new parameters in do_clone(int argc, char** argv).

2011-04-13 Thread 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 philipp.andr...@gmail.com
---
 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, source [dest/]name\n
-   Create a writable snapshot of the subvolume source with\n
+   { do_clone, -2,
+ subvolume snapshot, [-r] source [dest/]name\n
+   Create a writable/readonly snapshot of the subvolume source 
with\n
the name name in the dest 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 3/5] Added support for an additional ioctl.

2011-04-13 Thread 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 philipp.andr...@gmail.com
---
 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.

2011-04-13 Thread Andreas Philipp

Signed-off-by: Andreas Philipp philipp.andr...@gmail.com
---
 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 1/5] Add support for read-only subvolumes.

2011-04-13 Thread 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 philipp.andr...@gmail.com
---
 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(res0){
@@ -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 5/5] Updated documentation for btrfs subvolume snapshot.

2011-04-13 Thread Andreas Philipp

Signed-off-by: Andreas Philipp philipp.andr...@gmail.com
---
 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 source [dest/]name\fP
+\fBbtrfs\fP \fBsubvolume snapshot\fP\fI [-r] source [dest/]name\fP
 .PP
 \fBbtrfs\fP \fBsubvolume delete\fP\fI subvolume\fP
 .PP
@@ -70,10 +70,11 @@ command.
 .SH COMMANDS
 .TP
 
-\fBsubvolume snapshot\fR\fI source [dest/]name\fR
-Create a writable snapshot of the subvolume \fIsource\fR with the name
-\fIname\fR in the \fIdest\fR directory. If \fIsource\fR is not a
-subvolume, \fBbtrfs\fR returns an error.
+\fBsubvolume snapshot\fR\fI [-r] source [dest/]name\fR
+Create a writable/readonly snapshot of the subvolume \fIsource\fR with the
+name \fIname\fR in the \fIdest\fR directory. If \fIsource\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 subvolume\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


Re: [PATCH V3] Btrfs: fix subvolume mount by name problem when default mount subvolume is set

2011-04-06 Thread 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 xin.zh...@intel.com
 ---
 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_locked_super(s);
 + goto error_free_subvol_name;
 + }
 }

 mnt-mnt_sb = s;
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQIcBAEBAgAGBQJNnCaeAAoJEJIcBJ3+Xkgi8AYP/2kZW9AkQOJoCFQiDipTF5ck
yeXqKAqaMnmry0XY3I3ideZKpFp5C1U6QqoA/uy/ieHDx1OPix+wciLuqo/uxbKj
LG3bKJTEcZ5swdjY6oHsTp9iQFXn5tNHTb0Sayha6QaJgkQ/FU4AV5jPmXdN5DvE
xGuaY08rvshE2Bm6nqG5KpRIeuaPoGRd7qFvorhzzMDZ1bEZ8OcbDy4q4SgTR3ji
mgDARmtnh38IASIb5/6CXLVsCgMf2t4lKlXA6pwFXruKyOfxNBRUzPjyTNuuErli
6b4/eHPn4lmhNelvScnCs6zHxdRQQAheX4r7uRQ+eSQmR+6DzZg9p+1TJcfr3/mn
18LRhGaCgFs5mXVwA+5bDQghcTZpFAePRa5hDxUvw2XKBq2

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

2011-03-30 Thread 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 philipp.andr...@gmail.com
 Signed-off-by: Li Zefan l...@cn.fujitsu.com
Tested-by: Andreas Philipp philipp.andr...@gmail.com
 ---
 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/
 
iQIcBAEBAgAGBQJNktS2AAoJEJIcBJ3+XkgiB4gP/RqCnQQj2RcM0pxpjPqA0+GE
HC5DqXGhqYa+6Y+WIKWZJIuhpxF+x5c885U7MBYU1f5UJB6bXttYVGE5Gq7pXgs5
aWezaX3WKIOsgfLWVRFezWtlmWvUuBgz3K2cLq9U+NcUNp13KjP4nI5QWwn0xo27
o4GjqdtHiN3Fen8/BCVUTHySUlFxqo2o7DvNB9KysW8Vz0zOS8Y0SXgUN+4u5p7L
7Y76UOiayMpVF6JaGQzcqGgf5WQyA8xWtYUAzuxBs+MA1Xfbogu4Oen59FKxR4BI
c0Ihw2GddQfxHvGQLXXXK2BuCpZfbpTD3hdxRnAzRspk8OqpBU0DYnZv0YybsqLw
XC+PM+oEUtsTAxaID0MWcoqfk40S54xv36PXgKF0RjIogJFRyxq1vNNCR5hzxVRX
hjVvBc31QWyE+EkFZKBWnuVqnfVwHa0Ya9S93+dIVxD6uBcnQWSmuZagP3Awi7Xb

read-only subvolumes?

2011-03-23 Thread 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: read-only subvolumes?

2011-03-23 Thread 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


Re: read-only subvolumes?

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

2011-03-20 Thread 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

2011-03-19 Thread 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?

2011-03-08 Thread 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 artafi...@gmail.com
 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
 r...@noir.com 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

2011-01-20 Thread 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

2010-11-17 Thread 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.

2010-11-12 Thread 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

2010-10-17 Thread 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

2010-10-09 Thread 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, path\n
 List the snapshot/subvolume of a filesystem. }, + {
 do_set_default_subvol, 2, + subvolume set-default, id
 path\n + Set the subvolume of the filesystem path which will
 be mounted\n + as default. + }, { do_find_newer, 2, subvolume
 find-new, path last_gen\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] file|dir [file|dir...]\n Defragment a file or a
 directory. }, - { do_set_default_subvol, 2, - subvolume
 set-default, id path\n - Set the subvolume of the
 filesystem path which will be mounted\n - as default. - }, {
 do_fssync, 1, filesystem sync, path\n Force a sync on the
 filesystem path. @@ -89,7 +89,7 @@ static struct Command
 commands[] = { }, { do_df_filesystem, 1, filesystem df,
 path\n - Show space usage information for a mount point\n. +
 Show space usage information for a mount point. }, { do_balance,
 1, filesystem balance, path\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 id path\fP .PP +\fBbtrfs\fP \fBsubvolume
 find-new\fP\fI subvolume last_gen\fP +.PP +\fBbtrfs\fP
 \fBfilesystem balance\fP\fI path \fP +.PP \fBbtrfs\fP
 \fBfilesystem defrag\fP\fI file|dir [file|dir...]\fP .PP
 \fBbtrfs\fP \fBfilesystem sync\fP\fI path \fP @@ -25,8 +29,6 @@
 btrfs \- control a btrfs filesystem .PP \fBbtrfs\fP \fBdevice
 show\fP\fI dev|label [dev|label...]\fP .PP -\fBbtrfs\fP
 \fBdevice balance\fP\fI path \fP -.PP \fBbtrfs\fP \fBdevice
 add\fP\fI dev [dev..] path \fP .PP \fBbtrfs\fP \fBdevice
 delete\fP\fI dev [dev..] path \fP] @@ -102,6 +104,10 @@ Set
 the subvolume of the filesystem \fIpath\fR which is mounted as is
 returned by the \fBsubvolume list\fR command. .TP

 +\fBsubvolume find-new\fR\fI subvolume last_gen\fR +List the
 recently modified files in a subvolume, after \fIlast_gen\fR ID.
 +.TP + \fBfilesystem defragment\fP\fI file|dir
 [file|dir...]\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 \fIpath\fR +\fBfilesystem balance\fR
 \fIpath\fR Balance the chunks of the filesystem identified by
 \fIpath\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: [PATCH][btrfs progs] Update/clean up btrfs help and man page

2010-10-09 Thread 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 device and dev. I changed it to device.
- - The filesystem show command accepts also the argument type device.
- - 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 device and dev. I changed it to device.
- - The filesystem show command accepts also the argument type device.
- - 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, [uuid|label]\n
+  filesystem show, [device|uuid|label]\n
 Show the info of a btrfs filesystem. If no uuid or label\n
 is passed, info of all the btrfs filesystem are shown.
 },
@@ -96,17 +96,17 @@ static struct Command commands[] = {
   filesystem balance, path\n
 Balance the chunks across the device.
 },
- -{ do_scan,
- -  999, device scan, [device [device..]\n
+{ do_scan, 999,
+  device scan, [device...]\n
 Scan all device for or the passed device for a btrfs\n
 filesystem.
 },
 { do_add_volume, -2,
- -  device add, dev [dev..] path\n
+  device add, device [device...] path\n
 Add a device to a filesystem.
 },
 { do_remove_volume, -2,
- -  device delete, dev [dev..] path\n
+  device delete, device [device...] path\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 path \fP
 .PP
- -\fBbtrfs\fP \fBfilesystem defrag\fP\fI [-vcf] [-s start] [-l len] [-t
size] file|dir [file|dir...]\fP
+\fBbtrfs\fP \fBfilesystem defragment\fP\fI [-vcf] [-s start] [-l len]
[-t size] file|dir [file|dir...]\fP
 .PP
 \fBbtrfs\fP \fBfilesystem sync\fP\fI path \fP
 .PP
 \fBbtrfs\fP \fBfilesystem resize\fP\fI
[devid:][+/\-]size[gkm]|max filesystem\fP
 .PP
- -\fBbtrfs\fP \fBdevice scan\fP\fI [device [device..]]\fP
+\fBbtrfs\fP \fBdevice scan\fP\fI [device...]\fP
 .PP
- -\fBbtrfs\fP \fBdevice show\fP\fI dev|label [dev|label...]\fP
+\fBbtrfs\fP \fBdevice show\fP\fI [device|uuid|label]\fP
 .PP
- -\fBbtrfs\fP \fBdevice add\fP\fI dev [dev..] path \fP
+\fBbtrfs\fP \fBdevice add\fP\fI device [device...] path \fP
 .PP
- -\fBbtrfs\fP \fBdevice delete\fP\fI dev [dev..] path \fP]
+\fBbtrfs\fP \fBdevice delete\fP\fI [device...] path \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 \fBsize\fR is
 considered already defragged.
 .TP
 
- -\fBdevice scan\fR \fI[device [device..]]\fR
+\fBdevice scan\fR \fI[device...]\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 [uuid|label]\fR
+\fBfilesystem show\fR [device|uuid|label]\fR
 Show the btrfs filesystem with some

Re: Francis Galiegue would like your help testing a survey

2010-09-28 Thread 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 fgalie...@gmail.com
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=376617crc=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


Re: machine gets unresponsive during btrfs balance

2010-08-29 Thread 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


btrfs-progs: error in manage

2010-08-29 Thread 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 [+/\-]size[gkm]|max
filesystem\fP
 .PP
+\fBbtrfs\fP \fBfilesystem balance\fP\fI path \fP
+.PP
 \fBbtrfs\fP \fBdevice scan\fP\fI [device [device..]]\fP
 .PP
 \fBbtrfs\fP \fBdevice show\fP\fI dev|label [dev|label...]\fP
 .PP
- -\fBbtrfs\fP \fBdevice balance\fP\fI path \fP
- -.PP
 \fBbtrfs\fP \fBdevice add\fP\fI dev [dev..] path \fP
 .PP
 \fBbtrfs\fP \fBdevice delete\fP\fI dev [dev..] path \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 \fIpath\fR
+\fBfilesystem balance\fR \fIpath\fR
 Balance the chunks of the filesystem identified by \fIpath\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

2010-08-26 Thread 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
 philipp.andr...@gmail.com 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

2010-08-20 Thread Andreas Philipp

 On 20.08.2010 20:27, Josh Berry wrote:

On Fri, Aug 20, 2010 at 05:03, Goffredo Baroncellikreij...@gmail.com  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: [RFC] Move all btrfs command to only one command

2010-08-20 Thread Andreas Philipp

 On 20.08.2010 20:49, Josh Berry wrote:

On Fri, Aug 20, 2010 at 11:34, Andreas Philipp
philipp.andr...@gmail.com  wrote:

  On 20.08.2010 20:27, Josh Berry wrote:

On Fri, Aug 20, 2010 at 05:03, Goffredo Baroncellikreij...@gmail.com
  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: machine gets unresponsive during btrfs balance

2010-08-13 Thread Andreas Philipp
On 12.08.2010 10:04, Yan, Zheng wrote:
 On Thu, Aug 12, 2010 at 3:14 PM, Andreas Philipp
 philipp.andr...@gmail.com 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


Re: machine gets unresponsive during btrfs balance

2010-08-13 Thread Andreas Philipp
On 12.08.2010 10:04, Yan, Zheng wrote:
 On Thu, Aug 12, 2010 at 3:14 PM, Andreas Philipp
 philipp.andr...@gmail.com 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


machine gets unresponsive during btrfs balance

2010-08-12 Thread 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

2010-05-31 Thread 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

2010-05-15 Thread 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?

2010-05-13 Thread 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

2010-02-17 Thread 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, dev [dev..] path\n
-   Remove a device to a filesystem
+   Remove a device from a filesystem
},
/* coming soon
{ 2, label, -m, label path\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 [dest/]name
 Create a writeble snapshot of the subvolume source with
 the name name in the dest directory.
 btrfs delete|-D subvolume
 Delete the subvolume subvolume.
 btrfs subvolume|-c [dest/]name
 Create a subvolume in dest (or the current directory if
 not passed).
 btrfs defrag|-f file|dir [file|dir...]
 Defragment a file or a directory.
 btrfs scan|-n [device [device..]
 Scan all device for or the passed device for a btrfs
 filesystem.
 btrfs fssync|-y path
 Force a fs sync on the filesystem path
 btrfs resize|-z [+/-]newsize[gkm]|max filesystem
 Resize the file system. If 'max' is passed, the filesystem
 will occupe all available space on the device.
 btrfs show|-l [dev|label...]
 Show the btrfs devices
 btrfs balance|-b path
 Balance the chunk across the device
 btrfs add-dev|-A dev [dev..] path
 Add a device to a filesystem
 btrfs rm-dev|-R dev [dev..] path
 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  source [dest/]name

btrfs  delete|-D  subvolume

btrfs  subvolume|-c  [dest/]name

btrfs  defrag|-f  file|dir [file|dir...]

btrfs  fssync|-y  path

btrfs  resize|-z  [+/-]size[gkm]|max filesystem

btrfs  scan|-n  [device [device..]]

btrfs  show|-l  dev|label [dev|label...]

btrfs  balance|-b  path

btrfs  add-dev|-A  dev [dev..] path

btrfs  rm-dev|-R  dev [dev..] path ]


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 source [dest/]name
   Create a writeble snapshot of the subvolume  source  with  the
   name  name  in the dest directory. If source is not a sub‐
   volume, btrfs returns an error. 


delete|-D subvolume
   Delete the subvolume subvolume. If subvolume is not  a  sub‐
   volume, btrfs returns an error. 


subvolume|-c [dest/]name
   Create  a  subvolume  in  dest (or in the current directory if
   dest is not passed).  


defrag|-f file|dir [file|dir...]
   Defragment files and/or directories.


scan|-n [device [device..]]
   Scan devices for a btrfs filesystem. If no devices