[PATCH 1/2] Btrfs: cleanup unnecessary clear when freeing a transaction or a trans handle

2012-11-15 Thread Miao Xie 
We clear the transaction object and the trans handle when they are about to be
freed, it is unnecessary, cleanup it.

Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
 fs/btrfs/transaction.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index d9a9a70..9930888 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -39,7 +39,6 @@ void put_transaction(struct btrfs_transaction *transaction)
if (atomic_dec_and_test(transaction-use_count)) {
BUG_ON(!list_empty(transaction-list));
WARN_ON(transaction-delayed_refs.root.rb_node);
-   memset(transaction, 0, sizeof(*transaction));
kmem_cache_free(btrfs_transaction_cachep, transaction);
}
 }
@@ -644,7 +643,6 @@ static int __btrfs_end_transaction(struct 
btrfs_trans_handle *trans,
}
assert_qgroups_uptodate(trans);
 
-   memset(trans, 0, sizeof(*trans));
kmem_cache_free(btrfs_trans_handle_cachep, trans);
return err;
 }
-- 
1.7.11.7
--
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/2] Btrfs: use common work instead of delayed work

2012-11-15 Thread Miao Xie 
Since we do not want to delay the async transaction commit, we should
use common work, not delayed work.

Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
 fs/btrfs/transaction.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index 9930888..a367df6 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -1296,13 +1296,13 @@ static void 
wait_current_trans_commit_start_and_unblock(struct btrfs_root *root,
 struct btrfs_async_commit {
struct btrfs_trans_handle *newtrans;
struct btrfs_root *root;
-   struct delayed_work work;
+   struct work_struct work;
 };
 
 static void do_async_commit(struct work_struct *work)
 {
struct btrfs_async_commit *ac =
-   container_of(work, struct btrfs_async_commit, work.work);
+   container_of(work, struct btrfs_async_commit, work);
 
/*
 * We've got freeze protection passed with the transaction.
@@ -1329,7 +1329,7 @@ int btrfs_commit_transaction_async(struct 
btrfs_trans_handle *trans,
if (!ac)
return -ENOMEM;
 
-   INIT_DELAYED_WORK(ac-work, do_async_commit);
+   INIT_WORK(ac-work, do_async_commit);
ac-root = root;
ac-newtrans = btrfs_join_transaction(root);
if (IS_ERR(ac-newtrans)) {
@@ -1351,7 +1351,7 @@ int btrfs_commit_transaction_async(struct 
btrfs_trans_handle *trans,
rwsem_release(root-fs_info-sb-s_writers.lock_map[SB_FREEZE_FS-1],
  1, _THIS_IP_);
 
-   schedule_delayed_work(ac-work, 0);
+   schedule_work(ac-work);
 
/* wait for transaction to start and unblock */
if (wait_for_unblock)
-- 
1.7.11.7
--
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: problem with ceph and btrfs patch: set journal_info in async trans commit worker

2012-11-15 Thread Stefan Priebe - Profihost AG 

Hi Miao,

Am 15.11.2012 06:18, schrieb Miao Xie:

Hi, Stefan

On wed, 14 Nov 2012 14:42:07 +0100, Stefan Priebe - Profihost AG wrote:

Hello list,

i wanted to try out ceph with latest vanilla kernel 3.7-rc5. I was seeing a 
massive performance degration. I see around 22x btrfs-endio-write processes 
every 10-20 seconds and they run a long time while consuming a massive amount 
of CPU.

So my performance of 23.000 iops drops to an up and down of 23.000 iops to 0 - 
avg is now 2500 iops instead of 23.000.

Git bisect shows me commit: e209db7ace281ca347b1ac699bf1fb222eac03fe Btrfs: set 
journal_info in async trans commit worker as the problematic patch.

When i revert this one everything is fine again.

Is this known?


Could you try the following patch?

http://marc.info/?l=linux-btrfsm=135175512030453w=2

I think the patch

   Btrfs: set journal_info in async trans commit worker

is not the real reason that caused the regression.

I guess it is caused by the bug of the reservation. When we join the
same transaction handle more than 2 times, the pointer of the reservation
in the transaction handle would be lost, and the statistical data in the
reservation would be corrupted. And then we would trigger the space flush,
which may block your tasks.


i applied your whole patchset. It looks a lot better now but avg iops is 
now 5000 iops and not 23.000 like when removing the mentioned commit 
(e209db7ace281ca347b1ac699bf1fb222eac03fe).


Stefan
--
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: corrupt leaf, bad key order

2012-11-15 Thread Olivier Bonvalet 
Hi,

in my logs I have :
[482886.171753] btrfs: corrupt leaf, bad key order: block=5484560384,root=1, 
slot=39
[482890.537049] btrfs: corrupt leaf, bad key order: block=5484560384,root=1, 
slot=39
[482940.827007] btrfs: corrupt leaf, bad key order: block=5484560384,root=1, 
slot=39
[482940.827048] BTRFS warning (device dm-1): Aborting unused transaction.
[482943.482879] btrfs: corrupt leaf, bad key order: block=5484560384,root=1, 
slot=39
[482943.482918] BTRFS warning (device dm-1): Aborting unused transaction.
[482943.889685] btrfs: corrupt leaf, bad key order: block=5484560384,root=1, 
slot=39
[482944.006944] btrfs: corrupt leaf, bad key order: block=5484560384,root=1, 
slot=39
[482944.118946] btrfs: corrupt leaf, bad key order: block=5484560384,root=1, 
slot=39
[482944.118977] BTRFS warning (device dm-1): Aborting unused transaction.
[482944.118980] BTRFS warning (device dm-1): Aborting unused transaction.
[482944.118991] BTRFS warning (device dm-1): Aborting unused transaction.
[482944.191122] btrfs: corrupt leaf, bad key order: block=5484560384,root=1, 
slot=39
[482944.267567] btrfs: corrupt leaf, bad key order: block=5484560384,root=1, 
slot=39
[482944.267598] BTRFS warning (device dm-1): Aborting unused transaction.
[482944.267601] BTRFS warning (device dm-1): Aborting unused transaction.
[482944.465267] btrfs: corrupt leaf, bad key order: block=5484560384,root=1, 
slot=39
[482944.465301] BTRFS warning (device dm-1): Aborting unused transaction.
[482944.537176] btrfs: corrupt leaf, bad key order: block=5484560384,root=1, 
slot=39
[482944.537226] BTRFS warning (device dm-1): Aborting unused transaction.
[482944.645056] btrfs: corrupt leaf, bad key order: block=5484560384,root=1, 
slot=39
[482944.645091] BTRFS warning (device dm-1): Aborting unused transaction.
[482944.703298] btrfs: corrupt leaf, bad key order: block=5484560384,root=1, 
slot=39
[482944.774537] btrfs: corrupt leaf, bad key order: block=5484560384,root=1, 
slot=39
[482944.774565] BTRFS error (device dm-1) in btrfs_finish_ordered_io:1938: IO 
failure
[482944.774572] btrfs is forced readonly
[482944.774580] BTRFS warning (device dm-1): Aborting unused transaction.


How can I fix that ? (seen from a 3.6.6 kernel, but don't know when the
error occurred)

Thanks,
Olivier




--
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] Btrfs: disable qgroup id 0

2012-11-15 Thread Miao Xie 
Qgroup id 0 is a special number, we should set the id of a qgroup to 0.
Fix it.

Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
 fs/btrfs/ioctl.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 8e5b7fa..922a33a 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -3574,6 +3574,11 @@ static long btrfs_ioctl_qgroup_create(struct btrfs_root 
*root, void __user *arg)
if (IS_ERR(sa))
return PTR_ERR(sa);
 
+   if (!sa-qgroupid) {
+   ret = -EINVAL;
+   goto out;
+   }
+
trans = btrfs_join_transaction(root);
if (IS_ERR(trans)) {
ret = PTR_ERR(trans);
-- 
1.7.11.7
--
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] btrfs-progs: remove unnecessary assignment in btrfs-map-logical.c

2012-11-15 Thread Wang Sheng-Hui 
The info_file is set to stdout by default, and we donot need to
reassign it to stdout if it's not changed to other values.

Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
 btrfs-map-logical.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/btrfs-map-logical.c b/btrfs-map-logical.c
index fa4fb3f..2ecaabd 100644
--- a/btrfs-map-logical.c
+++ b/btrfs-map-logical.c
@@ -187,7 +187,6 @@ int main(int ac, char **av)
close(out_fd);
goto close;
}
-   info_file = stdout;
}
}

-- 
1.7.5.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: Cannot list subvolumes with latest git

2012-11-15 Thread Jan Schmidt 
On Wed, November 14, 2012 at 19:26 (+0100), Jérôme Poulin wrote:
 Using Debian experimental kernel, 3.6.4-1~experimental.1, and latest
 btrfs tools from git master, I am not able to execute btrfs subvolume
 list.
 
 # ./btrfs sub li /mnt/data0/
 ERROR: Failed to lookup path for root 0 - No such file or directory
 
 After bisecting with git, I was able to confirm that commit
 162df1e30c7c0492ae9fb551d74452e643f5fea2 breaks btrfs subvolume list
 on my current kernel.

I can confirm this. Steps to reproduce:

- create subvolume
- put some data in
- delete subvolume
- call btrfs subvol list immediately

If you give it some time, listing of subvolumes eventually works. Calling sync
doesn't help, surprisingly, while umount/mount does.

Some add_root get's called with ref_tree = 0, which in turn makes
lookup_ino_path call BTRFS_IOC_INO_LOOKUP with a treeid of 0, which looks wrong
to me. I haven't looked any closer.

Miao, as that was your patch, can you probably check if you can reproduce the
problem?

Thanks,
-Jan
--
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: Several unhappy btrfs's after RAID meltdown

2012-11-15 Thread Ryan C. Underwood 

Finally made some more progress on one of my melted down btrfs from
earlier this year.

First I hacked find-root.c to not stop scanning the disk when it
thinks it has found the real root.  I wanted it to print out all
possible roots.  I saved the stderr output to a logfile.  About 1226
possible roots were found.

Then I used btrfs-restore, iterating over each one of these to
attempt to use each one of them as the root and see what files could
be found:

for temp in `sed 's/^.*block \([0-9]\+\).*$/\1/' log`;
do echo $temp;
nice ./btrfs-restore -t $temp /dev/mapper/tr5ut-vicep--library 
/mnt/recovery;
done

In this way I was able to recover about 36GB of data and the
directory structure of what is recovered looks fine.  The data also
looks fine too by scanning MIME types with file and selecting a few
text or HTML files to check manually.

There is still a lot of data missing though.  If I am reading this
correctly there was about 300GB of data which compressed to 254GB
on-disk.

Label: 'vicep-library'  uuid: 89b14d35-b31a-4fbe-a2d9-cb83cbcd3851
Total devices 1 FS bytes used 254.35GB
devid1 size 1.00TB used 299.04GB path /dev/dm-27

A lot of my btrfs-restore output looks like this:

318259351552
parent transid verify failed on 318259351552 wanted 575931 found 546662
parent transid verify failed on 318259351552 wanted 575931 found 546662
parent transid verify failed on 318259351552 wanted 575931 found 546662
parent transid verify failed on 318259351552 wanted 575931 found 546662
Ignoring transid failure
parent transid verify failed on 318125375488 wanted 541528 found 572360
parent transid verify failed on 318125375488 wanted 541528 found 572360
parent transid verify failed on 318125375488 wanted 541528 found 572360
parent transid verify failed on 318125375488 wanted 541528 found 572360
Ignoring transid failure
parent transid verify failed on 561016832 wanted 544038 found 574369
parent transid verify failed on 561016832 wanted 544038 found 574369
parent transid verify failed on 561016832 wanted 544038 found 574369
parent transid verify failed on 561016832 wanted 544038 found 574369
Ignoring transid failure
leaf parent key incorrect 561016832
Root objectid is 5
parent transid verify failed on 164073472 wanted 544650 found 562972
parent transid verify failed on 164073472 wanted 544650 found 562972
parent transid verify failed on 164073472 wanted 544650 found 562972
parent transid verify failed on 164073472 wanted 544650 found 562972
Ignoring transid failure
leaf parent key incorrect 164073472
Error searching -1

As far as I can see only the #5 root object was found, at least I
don't see any others found in the output.  This could account for the
missing data.  How could I get to the other root objects?

-- 
Ryan C. Underwood, neme...@icequake.net


signature.asc
Description: Digital signature

[PATCH] btrfs-progs: fix 32bit int/pointer cast warnings

2012-11-15 Thread Zach Brown 
This uses uintptr_t to cast pointers to u64 ioctl arguments to silence
some 32bit build warnings:

cmds-inspect.c: In function ‘__ino_to_path_fd’:
cmds-inspect.c:47:15: warning: cast from pointer to integer of different size 
[-Wpointer-to-int-cast]
cmds-inspect.c: In function ‘cmd_logical_resolve’:
cmds-inspect.c:171:15: warning: cast from pointer to integer of different size 
[-Wpointer-to-int-cast]

Signed-off-by: Zach Brown z...@redhat.com
---
 cmds-inspect.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/cmds-inspect.c b/cmds-inspect.c
index edabff5..25b83d2 100644
--- a/cmds-inspect.c
+++ b/cmds-inspect.c
@@ -17,6 +17,7 @@
 #include stdio.h
 #include stdlib.h
 #include unistd.h
+#include stdint.h
 #include sys/ioctl.h
 #include errno.h
 
@@ -44,7 +45,7 @@ static int __ino_to_path_fd(u64 inum, int fd, int verbose, 
const char *prepend)
 
ipa.inum = inum;
ipa.size = 4096;
-   ipa.fspath = (u64)fspath;
+   ipa.fspath = (uintptr_t)fspath;
 
ret = ioctl(fd, BTRFS_IOC_INO_PATHS, ipa);
if (ret) {
@@ -168,7 +169,7 @@ static int cmd_logical_resolve(int argc, char **argv)
 
loi.logical = atoll(argv[optind]);
loi.size = size;
-   loi.inodes = (u64)inodes;
+   loi.inodes = (uintptr_t)inodes;
 
fd = open_file_or_dir(argv[optind+1]);
if (fd  0) {
-- 
1.7.11.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

Likely mem leak in 3.7

2012-11-15 Thread James Cloos 
Starting with 3.7 rc1, my workstation seems to loose ram.

Up until (and including) 3.6, used-(buffers+cached) was roughly the same
as sum(rss) (taking shared into account).  Now there is an approx 6G gap.

When the box first starts, it is clearly less swappy than with = 3.6; I
can't tell whether that is related.  The reduced swappiness persists.

It seems to get worse when I update packages (it runs Gentoo).  The
portage tree and overlays are on btrfs filesystems.  As is /var/log
(with compression, except for the distfiles fs).  The compilations
themselves are done in a tmpfs.  I CCed l-b because of that apparent
correlation.

My postgress db is on xfs (tested faster) and has a 3G shared segment,
but that recovers when the pg process is stopped; neither of those seem
to be implicated.

There are also several ext4 partitions, including / and /home.

Cgroups are configured, and openrc does put everything it starts into
its own directory under /sys/fs/cgroup/openrc.  But top(1) shows all
of the processes, and its idea of free mem does change with pg's use
of its shared segment.  So it doesn't *look* like the ram is hiding
in some cgroup.

The kernel does not log anything relevant to this.

Slabinfo gives some odd output.  It seems to think there are negative
quantities of some slabs:

Name   Objects ObjsizeSpace Slabs/Part/Cpu  O/S O %Fr %Ef 
Flg
:at-016   5632  1690.1K 18446744073709551363/0/275  256 
0   0 100 *a
:t-0483386  48   249.8K 18446744073709551558/22/119   
85 0  36  65 *
:t-1201022 120   167.9K 18446744073709551604/14/53   34 
0  34  73 *
blkdev_requests182 376   122.8K 18446744073709551604/7/27   21 
1  46  55 
ext4_io_end3481128   393.2K 18446744073709551588/0/40   29 
3   0  99 a

The largest entries it reports are:

Name   Objects ObjsizeSpace Slabs/Part/Cpu  O/S O %Fr %Ef 
Flg
ext4_inode_cache 38448 864   106.1M3201/566/39   37 3  17  31 a
:at-104 316429 10436.5M   8840/3257/92   39 0  36  89 *a
btrfs_inode  13271 98435.7M  1078/0/14   33 3   0  36 a
radix_tree_node  43785 56034.7M   2075/1800/45   28 2  84  70 a
dentry   64281 19214.3M   3439/1185/55   21 0  33  86 a
proc_inode_cache 15695 60812.1M 693/166/51   26 2  22  78 a
inode_cache  10730 544 6.0M   349/0/21   29 2   0  96 a
task_struct6285896 4.3M  123/23/105 3  17  84 

The total Space is much smaller than the missing ram.

The only other difference I see is that one process has left behind
several score zombies.  It is structured as a parent with several
worker kids, but the kids stay zombie even when the parent process
is stopped and restarted.  wchan shows that they are stuck in exit.
Their normal rss isn't enough to account for the missing ram, even
if it isn't reclaimed.  (Not to mention, ram != brains. :)

I haven't tried bisecting because of the time it takes to confirm the
problem (several hours of uptime).  I've only compiled (each of) the
rc tags, so v3.6 is that last known good and v3.7-rc1 is the first
known bad.

If there is anything that I missed, please let me know!

-JimC
-- 
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
--
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] btrfs: limit fallocate extent reservation to 256MB

2012-11-15 Thread Zach Brown 
Very large fallocate requests are cpu bound and result in extents with a
repeating pattern of ever decreasing size:

$ time fallocate -l 1T file
real0m13.039s

( an excerpt of the extents from btrfs-debug-tree: )
  prealloc data disk byte 1536292564992 nr 397312
  prealloc data disk byte 1536292962304 nr 196608
  prealloc data disk byte 1536293158912 nr 98304
  prealloc data disk byte 1536293257216 nr 49152
  prealloc data disk byte 1536293306368 nr 24576
  prealloc data disk byte 1536293330944 nr 12288
  prealloc data disk byte 1536293343232 nr 8192
  prealloc data disk byte 1536293351424 nr 4096
  prealloc data disk byte 1536293355520 nr 4096
  prealloc data disk byte 1536293359616 nr 4096

The excessive cpu use comes from __btrfs_prealloc_file_range() trying to
allocate the entire remaining size after each extent is allocated.
btrfs_reserve_extent() repeatedly cuts this requested size in half until
it gets down to the size that the allocators can return.  We limit the
problem for now by capping each reservation at 256 meg.

The small extents come from a masking bug when decreasing the requested
reservation size.  The high 32bits are cleared and the remaining low
bits might happen to reserve a small size.   Fix this by using
round_down() which properly casts the mask.

After these fixes huge fallocate requests are fast and result in nice
large extents:

$ time fallocate -l 1T file
real0m0.082s

  prealloc data disk byte 1112425889792 nr 268435456
  prealloc data disk byte 1112694325248 nr 268435456
  prealloc data disk byte 1112962760704 nr 268435456

Reported-by: Eric Sandeen sand...@redhat.com
Signed-off-by: Zach Brown z...@redhat.com
---
 fs/btrfs/extent-tree.c | 2 +-
 fs/btrfs/inode.c   | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 6d2329d..3ae6bc3 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -5951,7 +5951,7 @@ again:
if (ret == -ENOSPC) {
if (!final_tried) {
num_bytes = num_bytes  1;
-   num_bytes = num_bytes  ~(root-sectorsize - 1);
+   num_bytes = round_down(num_bytes, root-sectorsize);
num_bytes = max(num_bytes, min_alloc_size);
if (num_bytes == min_alloc_size)
final_tried = true;
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 9d80e70..7ad949e 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -8331,8 +8331,9 @@ static int __btrfs_prealloc_file_range(struct inode 
*inode, int mode,
}
}
 
-   ret = btrfs_reserve_extent(trans, root, num_bytes, min_size,
-  0, *alloc_hint, ins, 1);
+   ret = btrfs_reserve_extent(trans, root,
+  min(num_bytes, 256ULL * 1024 * 1024),
+  min_size, 0, *alloc_hint, ins, 1);
if (ret) {
if (own_trans)
btrfs_end_transaction(trans, root);
-- 
1.7.11.7

--
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 list subvolumes with latest git

2012-11-15 Thread Miao Xie 
On Thu, 15 Nov 2012 17:05:41 +0100, Jan Schmidt wrote:
 On Wed, November 14, 2012 at 19:26 (+0100), Jérôme Poulin wrote:
 Using Debian experimental kernel, 3.6.4-1~experimental.1, and latest
 btrfs tools from git master, I am not able to execute btrfs subvolume
 list.

 # ./btrfs sub li /mnt/data0/
 ERROR: Failed to lookup path for root 0 - No such file or directory

 After bisecting with git, I was able to confirm that commit
 162df1e30c7c0492ae9fb551d74452e643f5fea2 breaks btrfs subvolume list
 on my current kernel.
 
 I can confirm this. Steps to reproduce:
 
 - create subvolume
 - put some data in
 - delete subvolume
 - call btrfs subvol list immediately
 
 If you give it some time, listing of subvolumes eventually works. Calling 
 sync
 doesn't help, surprisingly, while umount/mount does.

When we delete a subvolume, we just delete its ref and backref, don't delete 
the tree
at once, it will be done by the cleaner thread, which is woke up after the 
transaction
thread commits a transaction, that is the deletion of the tree may not be done 
in the
current transaction. It is the reason why sync doesn't help.

 Some add_root get's called with ref_tree = 0, which in turn makes
 lookup_ino_path call BTRFS_IOC_INO_LOOKUP with a treeid of 0, which looks 
 wrong
 to me. I haven't looked any closer.

Right.

 Miao, as that was your patch, can you probably check if you can reproduce the
 problem?

This problem was fixed by the following patch several days ago, but the patch 
have not
been applied into Chris's btrfs-progs tree.

  Btrfs-progs: filter the deleted subvolumes when listing snapshots

You can pull it from the URL:

  git://github.com/miaoxie/btrfs-progs.git master

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

[Request for review v2] [RFC] Add label support for snapshots and subvols

2012-11-15 Thread Anand jain 
From: Anand Jain anand.j...@oracle.com

v1-v2:
This v2 patch accepts the review comments on the btrfs
kernel changes by Jan. and
Moved the get and set subvol label to under subvol sub-cmd
eg:
btrfs subvolume label /btrfs/ss5
btrfs su la /btrfs/ss5 ss5-label
btrfs su la /btrfs/ss5
ss5-label

v1:
 (This patch is for the review/test not yet for the integration).

 Here is an implementation of the feature to add label to the
 subvolume and snapshots. Which would help sysadmin to better manager
 the subvol and snapshots.

 This can be done in two ways, one - using attr which is user land
 only changes but drawback is able to change the label using the
 non btrfs cli. And the other way is to add a member to
 btrfs_root_item in the btrfs kernel to hold the label info for
 each snapshot and subvol. The drawback here is having to introduce
 V3 version of this structure. If there is any better way pls do share.
 The patch code is for the review.

Any comments/suggestion welcome.

Below is a demo of this new feature.

 btrfs fi label -t /btrfs/sv1 Prod-DB

 btrfs fi label -t /btrfs/sv1
Prod-DB

 btrfs su snap /btrfs/sv1 /btrfs/snap1-sv1
Create a snapshot of '/btrfs/sv1' in '/btrfs/snap1-sv1'
 btrfs fi label -t /btrfs/snap1-sv1

 btrfs fi label -t /btrfs/snap1-sv1 Prod-DB-sand-box-testing
 
 btrfs fi label -t /btrfs/snap1-sv1
Prod-DB-sand-box-testing


Anand Jain (3):
  Btrfs-progs: move open_file_or_dir() to utils.c
  Btrfs-progs: add feature to label subvol and snapshot
  Btrfs-progs: cmd option to show or set the subvol label

 Makefile |4 ++--
 btrfsctl.c   |7 ---
 btrfslabel.c |   45 +
 btrfslabel.h |4 +++-
 cmds-balance.c   |1 +
 cmds-inspect.c   |1 +
 cmds-qgroup.c|1 +
 cmds-quota.c |1 +
 cmds-subvolume.c |   38 ++
 commands.h   |3 ---
 common.c |   46 --
 ctree.h  |4 +++-
 ioctl.h  |2 ++
 man/btrfs.8.in   |6 ++
 print-tree.c |2 ++
 utils.c  |   30 --
 utils.h  |3 +++
 17 files changed, 140 insertions(+), 58 deletions(-)
 delete mode 100644 common.c

--
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/3] Btrfs-progs: move open_file_or_dir() to utils.c

2012-11-15 Thread Anand jain 
From: Anand Jain anand.j...@oracle.com

The definition of the function open_file_or_dir() is moved from common.c
to utils.c in order to be able to share some common code between scrub
and the device stats in the following step. That common code uses
open_file_or_dir(). Since open_file_or_dir() makes use of the function
dirfd(3), the required XOPEN version was raised from 6 to 7.

Signed-off-by: Anand Jain anand.j...@oracle.com
Original-Signed-off-by: Stefan Behrens sbehr...@giantdisaster.de
---
 Makefile |4 ++--
 btrfsctl.c   |7 ---
 cmds-balance.c   |1 +
 cmds-inspect.c   |1 +
 cmds-qgroup.c|1 +
 cmds-quota.c |1 +
 cmds-subvolume.c |1 +
 commands.h   |3 ---
 common.c |   46 --
 utils.c  |   30 --
 utils.h  |3 +++
 11 files changed, 42 insertions(+), 56 deletions(-)
 delete mode 100644 common.c

diff --git a/Makefile b/Makefile
index 4894903..8576d90 100644
--- a/Makefile
+++ b/Makefile
@@ -41,8 +41,8 @@ all: version $(progs) manpages
 version:
bash version.sh
 
-btrfs: $(objects) btrfs.o help.o common.o $(cmds_objects)
-   $(CC) $(CFLAGS) -o btrfs btrfs.o help.o common.o $(cmds_objects) \
+btrfs: $(objects) btrfs.o help.o $(cmds_objects)
+   $(CC) $(CFLAGS) -o btrfs btrfs.o help.o $(cmds_objects) \
$(objects) $(LDFLAGS) $(LIBS) -lpthread
 
 calc-size: $(objects) calc-size.o
diff --git a/btrfsctl.c b/btrfsctl.c
index 518684c..049a5f3 100644
--- a/btrfsctl.c
+++ b/btrfsctl.c
@@ -63,7 +63,7 @@ static void print_usage(void)
exit(1);
 }
 
-static int open_file_or_dir(const char *fname)
+static int btrfsctl_open_file_or_dir(const char *fname)
 {
int ret;
struct stat st;
@@ -91,6 +91,7 @@ static int open_file_or_dir(const char *fname)
}
return fd;
 }
+
 int main(int ac, char **av)
 {
char *fname = NULL;
@@ -128,7 +129,7 @@ int main(int ac, char **av)
snap_location = strdup(fullpath);
snap_location = dirname(snap_location);
 
-   snap_fd = open_file_or_dir(snap_location);
+   snap_fd = btrfsctl_open_file_or_dir(snap_location);
 
name = strdup(fullpath);
name = basename(name);
@@ -238,7 +239,7 @@ int main(int ac, char **av)
}
name = fname;
 } else {
-   fd = open_file_or_dir(fname);
+   fd = btrfsctl_open_file_or_dir(fname);
 }
 
if (name) {
diff --git a/cmds-balance.c b/cmds-balance.c
index 38a7426..6268b61 100644
--- a/cmds-balance.c
+++ b/cmds-balance.c
@@ -28,6 +28,7 @@
 #include volumes.h
 
 #include commands.h
+#include utils.h
 
 static const char * const balance_cmd_group_usage[] = {
btrfs [filesystem] balance command [options] path,
diff --git a/cmds-inspect.c b/cmds-inspect.c
index edabff5..79e069b 100644
--- a/cmds-inspect.c
+++ b/cmds-inspect.c
@@ -22,6 +22,7 @@
 
 #include kerncompat.h
 #include ioctl.h
+#include utils.h
 
 #include commands.h
 #include btrfs-list.h
diff --git a/cmds-qgroup.c b/cmds-qgroup.c
index 1525c11..cafc284 100644
--- a/cmds-qgroup.c
+++ b/cmds-qgroup.c
@@ -24,6 +24,7 @@
 #include ioctl.h
 
 #include commands.h
+#include utils.h
 
 static const char * const qgroup_cmd_group_usage[] = {
btrfs qgroup command [options] path,
diff --git a/cmds-quota.c b/cmds-quota.c
index cf9ad97..8481514 100644
--- a/cmds-quota.c
+++ b/cmds-quota.c
@@ -23,6 +23,7 @@
 #include ioctl.h
 
 #include commands.h
+#include utils.h
 
 static const char * const quota_cmd_group_usage[] = {
btrfs quota command [options] path,
diff --git a/cmds-subvolume.c b/cmds-subvolume.c
index ac39f7b..e3cdb1e 100644
--- a/cmds-subvolume.c
+++ b/cmds-subvolume.c
@@ -32,6 +32,7 @@
 #include ctree.h
 #include commands.h
 #include btrfs-list.h
+#include utils.h
 
 static const char * const subvolume_cmd_group_usage[] = {
btrfs subvolume command args,
diff --git a/commands.h b/commands.h
index bb6d2dd..8114a73 100644
--- a/commands.h
+++ b/commands.h
@@ -79,9 +79,6 @@ void help_ambiguous_token(const char *arg, const struct 
cmd_group *grp);
 
 void help_command_group(const struct cmd_group *grp, int argc, char **argv);
 
-/* common.c */
-int open_file_or_dir(const char *fname);
-
 extern const struct cmd_group subvolume_cmd_group;
 extern const struct cmd_group filesystem_cmd_group;
 extern const struct cmd_group balance_cmd_group;
diff --git a/common.c b/common.c
deleted file mode 100644
index 03f6570..000
--- a/common.c
+++ /dev/null
@@ -1,46 +0,0 @@
-/*
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public
- * License v2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY;

[PATCH v2] Btrfs: add label to snapshot and subvol

2012-11-15 Thread Anand jain 
From: Anand Jain anand.j...@oracle.com

v1-v2:
This adds a new member label in the btrfs_root_item struct,
which uses 32 bytes of the reserved 64 bytes. So that 
btrfs_root_item remains same.

Signed-off-by: Anand Jain anand.j...@oracle.com
---
 fs/btrfs/ctree.h   |   12 +++-
 fs/btrfs/ioctl.c   |   32 
 fs/btrfs/ioctl.h   |2 ++
 fs/btrfs/transaction.c |1 +
 4 files changed, 46 insertions(+), 1 deletions(-)

diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 994d255..039e11c 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -383,6 +383,7 @@ struct btrfs_header {
  */
 #define BTRFS_SYSTEM_CHUNK_ARRAY_SIZE 2048
 #define BTRFS_LABEL_SIZE 256
+#define BTRFS_SUBVOL_LABEL_SIZE 32
 
 /*
  * just in case we somehow lose the roots and are not able to mount,
@@ -759,7 +760,8 @@ struct btrfs_root_item {
struct btrfs_timespec otime;
struct btrfs_timespec stime;
struct btrfs_timespec rtime;
-   __le64 reserved[8]; /* for future */
+   char label[BTRFS_SUBVOL_LABEL_SIZE];
+   __le64 reserved[4]; /* for future */
 } __attribute__ ((__packed__));
 
 /*
@@ -2441,6 +2443,14 @@ static inline bool btrfs_root_readonly(struct btrfs_root 
*root)
 {
return (root-root_item.flags  cpu_to_le64(BTRFS_ROOT_SUBVOL_RDONLY)) 
!= 0;
 }
+static inline char * btrfs_root_label(struct btrfs_root_item *root_item)
+{
+   return (root_item-label);
+}
+static inline void btrfs_root_set_label(struct btrfs_root_item *root_item, 
char *val)
+{
+   memcpy(root_item-label, val, BTRFS_SUBVOL_LABEL_SIZE);
+}
 
 /* struct btrfs_root_backup */
 BTRFS_SETGET_STACK_FUNCS(backup_tree_root, struct btrfs_root_backup,
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index e58bd9d..aa4eb23 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -3725,6 +3725,34 @@ static int btrfs_ioctl_set_label(struct btrfs_root 
*root, void __user *arg)
return 0;
 }
 
+static int btrfs_ioctl_subvol_getlabel(struct btrfs_root *root,
+   void __user *arg)
+{
+   char *label;
+
+   label = btrfs_root_label(root-root_item);
+   if (copy_to_user(arg, label, BTRFS_SUBVOL_LABEL_SIZE))
+   return -EFAULT;
+   return 0;
+}
+
+static int btrfs_ioctl_subvol_setlabel(struct btrfs_root *root,
+   void __user *arg)
+{
+   char label[BTRFS_SUBVOL_LABEL_SIZE+1];
+   struct btrfs_trans_handle *trans;
+
+   if (copy_from_user(label, arg, BTRFS_SUBVOL_LABEL_SIZE))
+   return -EFAULT;
+   trans = btrfs_join_transaction(root);
+   if (IS_ERR(trans))
+   return PTR_ERR(trans);
+   btrfs_root_set_label(root-root_item, label);
+   btrfs_end_transaction(trans, root);
+
+   return 0;
+}
+
 long btrfs_ioctl(struct file *file, unsigned int
cmd, unsigned long arg)
 {
@@ -3827,6 +3855,10 @@ long btrfs_ioctl(struct file *file, unsigned int
return btrfs_ioctl_get_label(root, argp);
case BTRFS_IOC_SET_LABEL:
return btrfs_ioctl_set_label(root, argp);
+   case BTRFS_IOC_SUBVOL_GETLABEL:
+   return btrfs_ioctl_subvol_getlabel(root, argp);
+   case BTRFS_IOC_SUBVOL_SETLABEL:
+   return btrfs_ioctl_subvol_setlabel(root, argp);
}
 
return -ENOTTY;
diff --git a/fs/btrfs/ioctl.h b/fs/btrfs/ioctl.h
index 0c60fcb..1009a0c 100644
--- a/fs/btrfs/ioctl.h
+++ b/fs/btrfs/ioctl.h
@@ -455,4 +455,6 @@ struct btrfs_ioctl_send_args {
  struct btrfs_ioctl_get_dev_stats)
 #define BTRFS_IOC_GET_LABEL _IOR(BTRFS_IOCTL_MAGIC, 53, __u64)
 #define BTRFS_IOC_SET_LABEL _IOW(BTRFS_IOCTL_MAGIC, 54, __u64)
+#define BTRFS_IOC_SUBVOL_GETLABEL _IOWR(BTRFS_IOCTL_MAGIC, 55, __u64)
+#define BTRFS_IOC_SUBVOL_SETLABEL _IOW(BTRFS_IOCTL_MAGIC, 56, __u64)
 #endif
diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index 04bbfb1..0a3f8b3 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -1118,6 +1118,7 @@ static noinline int create_pending_snapshot(struct 
btrfs_trans_handle *trans,
memset(new_root_item-rtime, 0, sizeof(new_root_item-rtime));
btrfs_set_root_stransid(new_root_item, 0);
btrfs_set_root_rtransid(new_root_item, 0);
+   memset(new_root_item-label, 0, BTRFS_SUBVOL_LABEL_SIZE);
 
old = btrfs_lock_root_node(root);
ret = btrfs_cow_block(trans, root, old, NULL, 0, old);
-- 
1.7.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/3] Btrfs-progs: cmd option to show or set the subvol label

2012-11-15 Thread Anand jain 
From: Anand Jain anand.j...@oracle.com

Signed-off-by: Anand Jain anand.j...@oracle.com
---
 cmds-subvolume.c |   37 +
 man/btrfs.8.in   |6 ++
 2 files changed, 43 insertions(+), 0 deletions(-)

diff --git a/cmds-subvolume.c b/cmds-subvolume.c
index e3cdb1e..759eade 100644
--- a/cmds-subvolume.c
+++ b/cmds-subvolume.c
@@ -33,6 +33,7 @@
 #include commands.h
 #include btrfs-list.h
 #include utils.h
+#include btrfslabel.h
 
 static const char * const subvolume_cmd_group_usage[] = {
btrfs subvolume command args,
@@ -700,6 +701,41 @@ static int cmd_find_new(int argc, char **argv)
return 0;
 }
 
+static const char * const cmd_subvol_label_usage[] = {
+   btrfs subvolume label path [label],
+   Show or set label for the subvol or snapshot,
+   NULL
+};
+
+static int cmd_subvol_label(int argc, char **argv)
+{
+   struct stat st;
+   char label[BTRFS_SUBVOL_LABEL_SIZE+1];
+   int ret;
+
+   if (check_argc_min(argc, 2) || check_argc_max(argc, 3))
+   usage(cmd_subvol_label_usage);
+
+   if (stat(argv[1], st)  0) {
+   fprintf(stderr, Error: %s\n,strerror(errno));
+   return -errno;
+   }
+   if (!S_ISDIR(st.st_mode)) {
+   fprintf(stderr, Error: Not a dir\n);
+   return -1;
+   }
+   if (argc  2)
+   return set_subvol_label(argv[1], argv[2]);
+   else {
+   ret = get_subvol_label(argv[1], label);
+   if (ret)
+   return ret;
+   label[BTRFS_SUBVOL_LABEL_SIZE]=0;
+   printf(%s\n,label);
+   }
+   return 0;
+}
+
 const struct cmd_group subvolume_cmd_group = {
subvolume_cmd_group_usage, NULL, {
{ create, cmd_subvol_create, cmd_subvol_create_usage, NULL, 0 
},
@@ -711,6 +747,7 @@ const struct cmd_group subvolume_cmd_group = {
{ set-default, cmd_subvol_set_default,
cmd_subvol_set_default_usage, NULL, 0 },
{ find-new, cmd_find_new, cmd_find_new_usage, NULL, 0 },
+   { label, cmd_subvol_label, cmd_subvol_label_usage, NULL, 0 },
{ 0, 0, 0, 0, 0 }
}
 };
diff --git a/man/btrfs.8.in b/man/btrfs.8.in
index 9222580..aa225d9 100644
--- a/man/btrfs.8.in
+++ b/man/btrfs.8.in
@@ -17,6 +17,8 @@ btrfs \- control a btrfs filesystem
 .PP
 \fBbtrfs\fP \fBsubvolume get-default\fP\fI path\fP
 .PP
+\fBbtrfs\fP \fBsubvolume label\fP\fI path [label]\fP
+.PP
 \fBbtrfs\fP \fBfilesystem defragment\fP -c[zlib|lzo] [-l \fIlen\fR] \
 [-s \fIstart\fR] [-t \fIsize\fR] -[vf] \fIfile\fR|\fIdir\fR \
 [\fIfile\fR|\fIdir\fR...]
@@ -160,6 +162,10 @@ Get the default subvolume of the filesystem \fIpath\fR. 
The output format
 is similar to \fBsubvolume list\fR command.
 .TP
 
+\fBsubvolume label\fR\fI path [label]\fR
+Show or set \fI[label]\fR for the subvolume or the snapshot \fIpath\fR.
+.TP
+
 \fBfilesystem defragment\fP -c[zlib|lzo] [-l \fIlen\fR] [-s \fIstart\fR] \
 [-t \fIsize\fR] -[vf] \fIfile\fR|\fIdir\fR [\fIfile\fR|\fIdir\fR...]
 
-- 
1.7.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] Btrfs: add label to snapshot and subvol

2012-11-15 Thread Anand Jain 


Hi Jan,

 Thanks for the review. Just posted the v2 patch for the
 btrfs kernel patch.
 Which, used the btrfs_root_item reserved space and
 used join_transaction

-Anand

On 05/11/12 15:39, Jan Schmidt wrote:

Hi Anand,

Some comments on your kernel patch from a quick jump through:

On 01.11.2012 11:46, Anand jain wrote:

From: Anand Jain anand.j...@oracle.com

This modifies the struct btrfs_root_item to hold the label,
and make it v3 of this structure.

Signed-off-by: Anand Jain anand.j...@oracle.com
---
  fs/btrfs/ctree.h   |   14 ++
  fs/btrfs/ioctl.c   |   32 
  fs/btrfs/ioctl.h   |2 ++
  fs/btrfs/root-tree.c   |   44 +++-
  fs/btrfs/transaction.c |1 +
  5 files changed, 72 insertions(+), 21 deletions(-)

diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 994d255..b280256 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -759,6 +759,10 @@ struct btrfs_root_item {
struct btrfs_timespec otime;
struct btrfs_timespec stime;
struct btrfs_timespec rtime;
+
+   __le64 generation_v3;


What is that supposed to be?


+   char label[BTRFS_LABEL_SIZE]; /* Add label to subvol */
+   
__le64 reserved[8]; /* for future */
  } __attribute__ ((__packed__));


You can't do that. There's a reason why we've got reserved bytes for
future use. Never change the struct's size.


@@ -2428,6 +2432,8 @@ BTRFS_SETGET_STACK_FUNCS(root_last_snapshot, struct 
btrfs_root_item,
 last_snapshot, 64);
  BTRFS_SETGET_STACK_FUNCS(root_generation_v2, struct btrfs_root_item,
 generation_v2, 64);
+BTRFS_SETGET_STACK_FUNCS(root_generation_v3, struct btrfs_root_item,
+generation_v3, 64);
  BTRFS_SETGET_STACK_FUNCS(root_ctransid, struct btrfs_root_item,
 ctransid, 64);
  BTRFS_SETGET_STACK_FUNCS(root_otransid, struct btrfs_root_item,
@@ -2441,6 +2447,14 @@ static inline bool btrfs_root_readonly(struct btrfs_root 
*root)
  {
return (root-root_item.flags  cpu_to_le64(BTRFS_ROOT_SUBVOL_RDONLY)) 
!= 0;
  }
+static inline char * btrfs_root_label(struct btrfs_root *root)
+{
+   return (root-root_item.label);
+}
+static inline void btrfs_root_set_label(struct btrfs_root *root, char *val)
+{
+   memcpy(root-root_item.label,val,BTRFS_LABEL_SIZE);
+}

  /* struct btrfs_root_backup */
  BTRFS_SETGET_STACK_FUNCS(backup_tree_root, struct btrfs_root_backup,
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index e58bd9d..cce0128 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -3725,6 +3725,34 @@ static int btrfs_ioctl_set_label(struct btrfs_root 
*root, void __user *arg)
return 0;
  }

+static int btrfs_ioctl_subvol_getlabel(struct btrfs_root *root,
+   void __user *arg)
+{
+   char *label;
+
+   label = btrfs_root_label(root);
+   if (copy_to_user(arg, label, BTRFS_LABEL_SIZE))
+   return -EFAULT;
+   return 0;
+}
+
+static int btrfs_ioctl_subvol_setlabel(struct btrfs_root *root,
+   void __user *arg)
+{
+   char label[BTRFS_LABEL_SIZE];
+   struct btrfs_trans_handle *trans;
+
+   if (copy_from_user(label, arg, BTRFS_LABEL_SIZE))
+   return -EFAULT;
+   trans = btrfs_start_transaction(root, 1);
+   if (IS_ERR(trans))
+   return PTR_ERR(trans);
+   btrfs_root_set_label(root, label);
+   btrfs_commit_transaction(trans, root);


Why use start/commit instead of join/end here?


+   return 0;
+}
+
  long btrfs_ioctl(struct file *file, unsigned int
cmd, unsigned long arg)
  {
@@ -3827,6 +3855,10 @@ long btrfs_ioctl(struct file *file, unsigned int
return btrfs_ioctl_get_label(root, argp);
case BTRFS_IOC_SET_LABEL:
return btrfs_ioctl_set_label(root, argp);
+   case BTRFS_IOC_SUBVOL_GETLABEL:
+   return btrfs_ioctl_subvol_getlabel(root, argp);
+   case BTRFS_IOC_SUBVOL_SETLABEL:
+   return btrfs_ioctl_subvol_setlabel(root, argp);
}

return -ENOTTY;
diff --git a/fs/btrfs/ioctl.h b/fs/btrfs/ioctl.h
index 0c60fcb..1009a0c 100644
--- a/fs/btrfs/ioctl.h
+++ b/fs/btrfs/ioctl.h
@@ -455,4 +455,6 @@ struct btrfs_ioctl_send_args {
  struct btrfs_ioctl_get_dev_stats)
  #define BTRFS_IOC_GET_LABEL _IOR(BTRFS_IOCTL_MAGIC, 53, __u64)
  #define BTRFS_IOC_SET_LABEL _IOW(BTRFS_IOCTL_MAGIC, 54, __u64)
+#define BTRFS_IOC_SUBVOL_GETLABEL _IOWR(BTRFS_IOCTL_MAGIC, 55, __u64)
+#define BTRFS_IOC_SUBVOL_SETLABEL _IOW(BTRFS_IOCTL_MAGIC, 56, __u64)
  #endif
diff --git a/fs/btrfs/root-tree.c b/fs/btrfs/root-tree.c
index eb923d0..2a9ae5f 100644
--- a/fs/btrfs/root-tree.c
+++ b/fs/btrfs/root-tree.c
@@ -35,32 +35,34 @@ void btrfs_read_root_item(struct btrfs_root *root,
  {
uuid_le uuid;
int

Re: [RFC v4+ hot_track 02/19] vfs: initialize and free data structures

2012-11-15 Thread Zhi Yong Wu 
On Wed, Nov 7, 2012 at 6:24 AM, David Sterba d...@jikos.cz wrote:
 On Mon, Oct 29, 2012 at 12:30:44PM +0800, zwu.ker...@gmail.com wrote:
 +/* Frees the entire hot_range_tree. */
 +static void hot_inode_item_free(struct kref *kref)
 +{
 + struct hot_comm_item *comm_item = container_of(kref,
 + struct hot_comm_item, refs);
 + struct hot_inode_item *he = container_of(comm_item,
 + struct hot_inode_item, hot_inode);
 +
 + hot_range_tree_free(he);
 + radix_tree_delete(he-hot_inode_tree, he-i_ino);

 void *radix_tree_delete(struct radix_tree_root *root, unsigned long index)

 and he::i_ino is u64, this will not work when
 sizeof(unsigned long) != sizeof(u64) (iirc this is a known limitation of
 radix tree implementation). This will work on 64bit only, not sure if
 this is intentional.
Fixed, thanks.

 + kmem_cache_free(hot_inode_item_cachep, he);
 +}
 +
 +/* Frees the entire hot_inode_tree. */
 +static void hot_inode_tree_exit(struct hot_info *root)
 +{
 + struct hot_inode_item *hi_nodes[8];
 + u64 ino = 0;
 + int i, n;

 nitpick, put the declarations on separate lines

 +
 + while (1) {
 + spin_lock(root-lock);
 + n = radix_tree_gang_lookup(root-hot_inode_tree,
 +(void **)hi_nodes, ino,
 +ARRAY_SIZE(hi_nodes));
 + if (!n) {
 + spin_unlock(root-lock);
 + break;
 + }
 +
 + ino = hi_nodes[n - 1]-i_ino + 1;
 + for (i = 0; i  n; i++)
 + hot_inode_item_put(hi_nodes[i]);
 + spin_unlock(root-lock);
 + }
 +}
 +
  /*
   * Initialize kmem cache for hot_inode_item and hot_range_item.
   */
 @@ -106,3 +197,36 @@ err:
   kmem_cache_destroy(hot_inode_item_cachep);
  }
  EXPORT_SYMBOL_GPL(hot_cache_init);
 +
 +/*
 + * Initialize the data structures for hot data tracking.
 + */
 +int hot_track_init(struct super_block *sb)
 +{
 + struct hot_info *root;
 + int ret = -ENOMEM;
 +
 + root = kzalloc(sizeof(struct hot_info), GFP_NOFS);
 + if (!root) {
 + printk(KERN_ERR %s: Failed to malloc memory for 
 + hot_info\n, __func__);
 + return ret;

 minor: you can drop the variable ret and just reurn ENOMEM here

 + }
 +
 + sb-s_hot_root = root;
 + hot_inode_tree_init(root);
 +
 + printk(KERN_INFO VFS: Turning on hot data tracking\n);
 +
 + return 0;
 +}
 +EXPORT_SYMBOL_GPL(hot_track_init);

 david



-- 
Regards,

Zhi Yong Wu
--
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: add label to snapshot and subvol

2012-11-15 Thread Miao Xie 
Hi, Anand

On fri, 16 Nov 2012 12:52:25 +0800, Anand jain wrote:
 +static int btrfs_ioctl_subvol_getlabel(struct btrfs_root *root,
 + void __user *arg)
 +{
 + char *label;
 +
 + label = btrfs_root_label(root-root_item);
 + if (copy_to_user(arg, label, BTRFS_SUBVOL_LABEL_SIZE))
 + return -EFAULT;
 + return 0;
 +}
 +
 +static int btrfs_ioctl_subvol_setlabel(struct btrfs_root *root,
 + void __user *arg)
 +{
 + char label[BTRFS_SUBVOL_LABEL_SIZE+1];
 + struct btrfs_trans_handle *trans;
 +
 + if (copy_from_user(label, arg, BTRFS_SUBVOL_LABEL_SIZE))
 + return -EFAULT;
 + trans = btrfs_join_transaction(root);
 + if (IS_ERR(trans))
 + return PTR_ERR(trans);
 + btrfs_root_set_label(root-root_item, label);
 + btrfs_end_transaction(trans, root);

We need a lock to protect the label, and besides that, we need to get the write
access before we set the label for the subvolume.

Thanks
Miao

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