[PATCH] btrfs-progs: btrfs_list_find_updated_files: Fix memory leak.

2013-10-06 Thread chandan
The current code returns from the function when the call to ioctl
fails. This may leak cache_dir_name and cache_full_name. Fix it.

Signed-off-by: chandan 
---
 btrfs-list.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/btrfs-list.c b/btrfs-list.c
index 9cadbf5..9411e4d 100644
--- a/btrfs-list.c
+++ b/btrfs-list.c
@@ -1686,7 +1686,7 @@ int btrfs_list_find_updated_files(int fd, u64 root_id, 
u64 oldest_gen)
if (ret < 0) {
fprintf(stderr, "ERROR: can't perform the search- %s\n",
strerror(e));
-   return ret;
+   break;
}
/* the ioctl returns the number of item it found in nr_items */
if (sk->nr_items == 0)
-- 
1.8.3.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] fs: btrfs: suppress compilation warnings

2013-10-06 Thread Chris Yungmann
This patch suppresses the following compilation warnings (mostly unused 
variables):

fs/btrfs/backref.c: In function 'iterate_inode_extrefs':
fs/btrfs/backref.c:1652:6: warning: variable 'slot' set but not used 
[-Wunused-but-set-variable]
  int slot;
  ^
fs/btrfs/ctree.c: In function 'btrfs_search_forward':
fs/btrfs/ctree.c:4917:8: warning: variable 'blockptr' set but not used 
[-Wunused-but-set-variable]
u64 blockptr;
^
fs/btrfs/disk-io.c: In function 'csum_dirty_buffer':
fs/btrfs/disk-io.c:468:25: warning: variable 'tree' set but not used 
[-Wunused-but-set-variable]
  struct extent_io_tree *tree;
 ^
fs/btrfs/disk-io.c: In function 'btree_readpage_end_io_hook':
fs/btrfs/disk-io.c:579:25: warning: variable 'tree' set but not used 
[-Wunused-but-set-variable]
  struct extent_io_tree *tree;
 ^
fs/btrfs/disk-io.c: In function 'btree_writepages':
fs/btrfs/disk-io.c:977:25: warning: variable 'tree' set but not used 
[-Wunused-but-set-variable]
  struct extent_io_tree *tree;
 ^
fs/btrfs/disk-io.c: In function 'btrfs_create_tree':
fs/btrfs/disk-io.c:1284:6: warning: variable 'bytenr' set but not used 
[-Wunused-but-set-variable]
  u64 bytenr;
  ^
fs/btrfs/disk-io.c: In function 'end_workqueue_fn':
fs/btrfs/disk-io.c:1695:24: warning: variable 'fs_info' set but not used 
[-Wunused-but-set-variable]
  struct btrfs_fs_info *fs_info;
^
fs/btrfs/extent_io.c: In function 'end_bio_extent_writepage':
fs/btrfs/extent_io.c:2349:25: warning: variable 'tree' set but not used 
[-Wunused-but-set-variable]
  struct extent_io_tree *tree;
 ^
fs/btrfs/extent_io.c:4099:33: warning: variable 'item' set but not used 
[-Wunused-but-set-variable]
  struct btrfs_file_extent_item *item;
 ^
fs/btrfs/extent_io.c: In function 'extent_fiemap':
fs/btrfs/extent_io.c:4104:16: warning: variable 'emflags' set but not used 
[-Wunused-but-set-variable]
  unsigned long emflags;
^
fs/btrfs/extent-tree.c: In function 'find_free_extent':
fs/btrfs/extent-tree.c:6133:7: warning: variable 'found_uncached_bg' set but 
not used [-Wunused-but-set-variable]
  bool found_uncached_bg = false;
   ^
fs/btrfs/inode.c: In function 'btrfs_new_inode':
fs/btrfs/inode.c:5356:6: warning: variable 'owner' set but not used 
[-Wunused-but-set-variable]
  int owner;
  ^
fs/btrfs/inode.c: In function 'btrfs_add_link':
fs/btrfs/inode.c:5544:7: warning: variable 'err' set but not used 
[-Wunused-but-set-variable]
   int err;
   ^
fs/btrfs/inode.c:5551:7: warning: variable 'err' set but not used 
[-Wunused-but-set-variable]
   int err;
   ^
fs/btrfs/qgroup.c: In function 'update_qgroup_limit_item':
fs/btrfs/qgroup.c:628:6: warning: variable 'slot' set but not used 
[-Wunused-but-set-variable]
  int slot;
  ^
fs/btrfs/qgroup.c: In function 'update_qgroup_info_item':
fs/btrfs/qgroup.c:671:6: warning: variable 'slot' set but not used 
[-Wunused-but-set-variable]
  int slot;
  ^
fs/btrfs/qgroup.c: In function 'btrfs_qgroup_account_ref':
fs/btrfs/qgroup.c:1352:19: warning: variable 'ins' set but not used 
[-Wunused-but-set-variable]
  struct btrfs_key ins;
   ^
fs/btrfs/raid56.c: In function 'finish_rmw':
fs/btrfs/raid56.c:1143:6: warning: variable 'p_stripe' set but not used 
[-Wunused-but-set-variable]
  int p_stripe = -1;
  ^
fs/btrfs/root-tree.c: In function 'btrfs_find_orphan_roots':
fs/btrfs/root-tree.c:230:7: warning: variable 'can_recover' set but not used 
[-Wunused-but-set-variable]
  bool can_recover = true;
   ^
fs/btrfs/scrub.c: In function 'scrub_fixup_nodatasum':
fs/btrfs/scrub.c:708:24: warning: variable 'fs_info' set but not used 
[-Wunused-but-set-variable]
  struct btrfs_fs_info *fs_info;
^
fs/btrfs/tree-log.c:1164:63: warning: incorrect type in argument 3 (different 
signedness)
fs/btrfs/tree-log.c:1164:63:expected unsigned int [usertype] *namelen
fs/btrfs/tree-log.c:1164:63:got int *
fs/btrfs/tree-log.c:1175:60: warning: incorrect type in argument 3 (different 
signedness)
fs/btrfs/tree-log.c:1175:60:expected unsigned int [usertype] *namelen
fs/btrfs/tree-log.c:1175:60:got int *
fs/btrfs/volumes.c: In function 'btrfs_uuid_scan_kthread':
fs/btrfs/volumes.c:3465:19: warning: variable 'max_key' set but not used 
[-Wunused-but-set-variable]
  struct btrfs_key max_key;
   ^

Signed-off-by: Chris Yungmann 
---
 fs/btrfs/backref.c |  4 ++--
 fs/btrfs/ctree.c   |  6 +-
 fs/btrfs/disk-io.c | 13 ++---
 fs/btrfs/extent-tree.c |  2 --
 fs/btrfs/extent_io.c   |  7 ---
 fs/btrfs/inode.c   | 19 +--
 fs/btrfs/qgroup.c  |  9 -
 fs/btrfs/raid56.c  |  9 ++---
 fs/btrfs/root-tree.c   |  4 
 fs/btrfs/scrub.c   |  2 --
 fs/btrfs/tree-log.c|  2 +-
 fs/btrfs/volumes.c |  5 -
 12 files changed, 13 insertions(+)

Re: [PATCH v2] btrfs-progs: calculate disk space that a subvol could free

2013-10-06 Thread Anand Jain


On 10/07/2013 11:01 AM, Wang Shilong wrote:
> On 10/07/2013 10:47 AM, Anand Jain wrote:
>>
>>
>>> If we want to speed up this progress, i think we can split it into two 
>>> parts:
>>>
>>> 1. First to search inline extent_data
>>> 2. Secondly search in extent tree to calculate (extent refs=1)
>>>
>>> This will avoid n*n rather than n+n which is better…
>>(sorry for delay in reply, I was on vacation).
>>
>>Thanks for what might help. I was kind of expecting
>>this when preliminary patch was sent before. Let me
>>try what you suggest and send out v3.
>>
>>I was also thinking if this should be inside kernel
>>facilitated by a new ioctl? so that we avoid number
>>of search ioctl thats required.
> Yeah, adding another ioctl maybe help. Anyway, there is another question.
> Did we need to consider metadata into subvolume's sole size?
> 
> Personaly, the answer is yes. Considering a subvolume is filled with a lot
> of empty files, but we get subvolume's sole size *0*.


 yes. Will consider for an update patch later.


Thanks, Anand
--
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: calculate disk space that a subvol could free

2013-10-06 Thread Wang Shilong
On 10/07/2013 10:47 AM, Anand Jain wrote:
>
>
>> If we want to speed up this progress, i think we can split it into two parts:
>>
>> 1. First to search inline extent_data
>> 2. Secondly search in extent tree to calculate (extent refs=1)
>>
>> This will avoid n*n rather than n+n which is better…
>   (sorry for delay in reply, I was on vacation).
>
>   Thanks for what might help. I was kind of expecting
>   this when preliminary patch was sent before. Let me
>   try what you suggest and send out v3.
>
>   I was also thinking if this should be inside kernel
>   facilitated by a new ioctl? so that we avoid number
>   of search ioctl thats required.
Yeah, adding another ioctl maybe help. Anyway, there is another question.
Did we need to consider metadata into subvolume's sole size?

Personaly, the answer is yes. Considering a subvolume is filled with a lot
of empty files, but we get subvolume's sole size *0*.


Thanks,
Wang
>
> Thanks, Anand
>
> --
> 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: [PATCH v2] btrfs-progs: calculate disk space that a subvol could free

2013-10-06 Thread Anand Jain



> If we want to speed up this progress, i think we can split it into two parts:
> 
> 1. First to search inline extent_data
> 2. Secondly search in extent tree to calculate (extent refs=1)
> 
> This will avoid n*n rather than n+n which is better…

  (sorry for delay in reply, I was on vacation).

  Thanks for what might help. I was kind of expecting
  this when preliminary patch was sent before. Let me
  try what you suggest and send out v3.

  I was also thinking if this should be inside kernel
  facilitated by a new ioctl? so that we avoid number
  of search ioctl thats required.

Thanks, Anand

--
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: kernel BUG at fs/btrfs/relocation.c:1060 during rebalancing

2013-10-06 Thread Guenther Starnberger
On Thu, Sep 26, 2013 at 07:26:07AM +0200, Guenther Starnberger wrote:

> Yes - this also happens on 3.12-rc kernels. Here's the stacktrace for 4b97280
> (which is several commits ahead of 3.12-rc2):

As an update to my previous mail: I just tried to continue the balance with an
updated btrfs-next kernel (4380ae355c5c17c150d29bf0c07f44046102ca2e) but I'm
still seeing the same issue:

[  273.810775] btrfs: disk space caching is enabled
[  273.812257] btrfs: has skinny extents
[  291.906125] BTRFS debug (device dm-0): unlinked 1 orphans
[  291.979115] btrfs: continuing balance
[  296.214254] btrfs: relocating block group 1542996361216 flags 1
[  411.032805] btrfs: found 18 extents
[  449.598891] [ cut here ]
[  449.600360] kernel BUG at fs/btrfs/relocation.c:1060!
[  449.601603] invalid opcode:  [#1] PREEMPT SMP 
[  449.601971] Modules linked in: btrfs raid6_pq crc32c libcrc32c zlib_deflate 
xor xts gf128mul dm_crypt dm_mod usb_storage snd_intel8x0 snd_ac97_codec 
ac97_bus psmouse snd_pcm snd_page_alloc snd_timer ppdev microcode snd joydev 
evdev pcspkr serio_raw parport_pc parport i2c_piix4 intel_agp intel_gtt mperf 
i2c_core e1000 soundcore processor battery button ac ext4 crc16 mbcache jbd2 
hid_generic usbhid hid sr_mod cdrom sd_mod ata_generic pata_acpi ohci_pci 
ata_piix ahci libahci ohci_hcd ehci_pci ehci_hcd usbcore usb_common libata 
scsi_mod
[  449.601971] CPU: 0 PID: 390 Comm: btrfs-balance Not tainted 
3.11.0-1-90707-g4380ae3-dirty #1
[  449.601971] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS 
VirtualBox 12/01/2006
[  449.601971] task: 88007ad45cd0 ti: 8800786e4000 task.ti: 
8800786e4000
[  449.601971] RIP: 0010:[]  [] 
build_backref_tree+0x112a/0x11d0 [btrfs]
[  449.601971] RSP: 0018:8800786e5ab8  EFLAGS: 00010246
[  449.601971] RAX:  RBX: 88007ad6e800 RCX: 8800780c81d0
[  449.601971] RDX: 8800786e5b30 RSI: 88007ad6e820 RDI: 8800780c81c0
[  449.601971] RBP: 8800786e5ba0 R08: 88007806d000 R09: 8800786e5a70
[  449.601971] R10:  R11:  R12: 
[  449.601971] R13: 88007888a120 R14: 88007806d600 R15: 8800780c81d0
[  449.601971] FS:  () GS:88007fa0() 
knlGS:
[  449.601971] CS:  0010 DS:  ES:  CR0: 8005003b
[  449.601971] CR2: 7fe6529864f0 CR3: 7bb99000 CR4: 06f0
[  449.601971] Stack:
[  449.601971]  88007806da80  8800780c8060 
88007806d000
[  449.601971]  88007806d000 88007888a120 88007ad6e000 
88007888a240
[  449.601971]  88007806d340 88007ad6e920 88007806da80 
88007ad6e924
[  449.601971] Call Trace:
[  449.601971]  [] relocate_tree_blocks+0x1d8/0x630 [btrfs]
[  449.601971]  [] relocate_block_group+0x280/0x690 [btrfs]
[  449.601971]  [] btrfs_relocate_block_group+0x19d/0x2e0 
[btrfs]
[  449.601971]  [] btrfs_relocate_chunk.isra.28+0x68/0x780 
[btrfs]
[  449.601971]  [] ? btrfs_search_slot+0x498/0x970 [btrfs]
[  449.601971]  [] ? release_extent_buffer+0xa9/0xd0 [btrfs]
[  449.601971]  [] ? free_extent_buffer+0x4f/0xa0 [btrfs]
[  449.601971]  [] btrfs_balance+0x913/0xeb0 [btrfs]
[  449.601971]  [] balance_kthread+0x70/0x80 [btrfs]
[  449.601971]  [] ? btrfs_balance+0xeb0/0xeb0 [btrfs]
[  449.601971]  [] kthread+0xc0/0xd0
[  449.601971]  [] ? kthread_create_on_node+0x120/0x120
[  449.601971]  [] ret_from_fork+0x7c/0xb0
[  449.601971]  [] ? kthread_create_on_node+0x120/0x120
[  449.601971] Code: 4c 89 ef e8 29 f0 f8 ff 48 8b bd 50 ff ff ff e8 1d f0 f8 
ff 48 83 bd 30 ff ff ff 00 0f 85 0c fd ff ff 31 c0 e9 ae ef ff ff 0f 0b <0f> 0b 
48 8b 85 30 ff ff ff 49 8d 7e 20 48 8b 70 18 48 89 c2 e8 
[  449.601971] RIP  [] build_backref_tree+0x112a/0x11d0 
[btrfs]
[  449.601971]  RSP 
[  449.645464] ---[ end trace 0478746bd226d078 ]---

- Guenther
--
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] Btrfs: improve inode hash function/inode lookup

2013-10-06 Thread Filipe David Borba Manana
Currently the hash value used for adding an inode to the VFS's inode
hash table consists of the plain inode number, which is a 64 bits
integer. This results in hash table buckets (hlist_head lists) with
too many elements for at least 2 important scenarios:

1) When we have many subvolumes. Each subvolume has its own btree
   where its files and directories are added to, and each has its
   own objectid (inode number) namespace. This means that if we have
   N subvolumes, and all have inode number X associated to a file or
   directory, the corresponding inodes all map to the same hash table
   entry, resulting in a bucket (hlist_head list) with N elements;

2) On 32 bits machines. Th VFS hash values are unsigned longs, which
   are 32 bits wide on 32 bits machines, and the inode (objectid)
   numbers are 64 bits unsigned integers. We simply cast the inode
   numbers to hash values, which means that for all inodes with the
   same 32 bits lower half, the same hash bucket is used for all of
   them. For example, all inodes with a number (objectid) between
   0x___ and 0x___ will end up in
   the same hash table bucket.

This change ensures the inode's hash value depends both on the
objectid (inode number) and its subvolume's (btree root) objectid.
For 32 bits machines, this change gives better entropy by making
the hash value depend on both the upper and lower 32 bits of the
64 bits hash previously computed.

Signed-off-by: Filipe David Borba Manana 
---

V2: Renamed function inode_hash() to btrfs_inode_hash().

 fs/btrfs/btrfs_inode.h |   20 
 fs/btrfs/disk-io.c |2 +-
 fs/btrfs/inode.c   |6 --
 3 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs_inode.h
index 71f074e..ac0b39d 100644
--- a/fs/btrfs/btrfs_inode.h
+++ b/fs/btrfs/btrfs_inode.h
@@ -19,6 +19,7 @@
 #ifndef __BTRFS_I__
 #define __BTRFS_I__
 
+#include 
 #include "extent_map.h"
 #include "extent_io.h"
 #include "ordered-data.h"
@@ -179,6 +180,25 @@ static inline struct btrfs_inode *BTRFS_I(struct inode 
*inode)
return container_of(inode, struct btrfs_inode, vfs_inode);
 }
 
+static inline unsigned long btrfs_inode_hash(u64 objectid,
+const struct btrfs_root *root)
+{
+   u64 h = objectid ^ (root->objectid * GOLDEN_RATIO_PRIME);
+
+#if BITS_PER_LONG == 32
+   h = (h >> 32) ^ (h & 0x);
+#endif
+
+   return (unsigned long)h;
+}
+
+static inline void btrfs_insert_inode_hash(struct inode *inode)
+{
+   unsigned long h = btrfs_inode_hash(inode->i_ino, BTRFS_I(inode)->root);
+
+   __insert_inode_hash(inode, h);
+}
+
 static inline u64 btrfs_ino(struct inode *inode)
 {
u64 ino = BTRFS_I(inode)->location.objectid;
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index ade6c0e..d205bdd 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -2294,7 +2294,7 @@ int open_ctree(struct super_block *sb,
   sizeof(struct btrfs_key));
set_bit(BTRFS_INODE_DUMMY,
&BTRFS_I(fs_info->btree_inode)->runtime_flags);
-   insert_inode_hash(fs_info->btree_inode);
+   btrfs_insert_inode_hash(fs_info->btree_inode);
 
spin_lock_init(&fs_info->block_group_cache_lock);
fs_info->block_group_cache_tree = RB_ROOT;
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 13b470c..cc3de9d 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -4837,10 +4837,12 @@ static struct inode *btrfs_iget_locked(struct 
super_block *s,
 {
struct inode *inode;
struct btrfs_iget_args args;
+   unsigned long hashval = btrfs_inode_hash(objectid, root);
+
args.ino = objectid;
args.root = root;
 
-   inode = iget5_locked(s, objectid, btrfs_find_actor,
+   inode = iget5_locked(s, hashval, btrfs_find_actor,
 btrfs_init_locked_inode,
 (void *)&args);
return inode;
@@ -5460,7 +5462,7 @@ static struct inode *btrfs_new_inode(struct 
btrfs_trans_handle *trans,
BTRFS_INODE_NODATASUM;
}
 
-   insert_inode_hash(inode);
+   btrfs_insert_inode_hash(inode);
inode_tree_add(inode);
 
trace_btrfs_inode_new(inode);
-- 
1.7.9.5

--
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: improve inode hash function/inode lookup

2013-10-06 Thread Filipe David Borba Manana
Currently the hash value used for adding an inode to the VFS's inode
hash table consists of the plain inode number, which is a 64 bits
integer. This results in hash table buckets (hlist_head lists) with
too many elements for at least 2 important scenarios:

1) When we have many subvolumes. Each subvolume has its own btree
   where its files and directories are added to, and each has its
   own objectid (inode number) namespace. This means that if we have
   N subvolumes, and all have inode number X associated to a file or
   directory, the corresponding inodes all map to the same hash table
   entry, resulting in a bucket (hlist_head list) with N elements;

2) On 32 bits machines. Th VFS hash values are unsigned longs, which
   are 32 bits wide on 32 bits machines, and the inode (objectid)
   numbers are 64 bits unsigned integers. We simply cast the inode
   numbers to hash values, which means that for all inodes with the
   same 32 bits lower half, the same hash bucket is used for all of
   them. For example, all inodes with a number (objectid) between
   0x___ and 0x___ will end up in
   the same hash table bucket.

This change ensures the inode's hash value depends both on the
objectid (inode number) and its subvolume's (btree root) objectid.
For 32 bits machines, this change gives better entropy by making
the hash value depend on both the upper and lower 32 bits of the
64 bits hash previously computed.

Signed-off-by: Filipe David Borba Manana 
---
 fs/btrfs/btrfs_inode.h |   20 
 fs/btrfs/disk-io.c |2 +-
 fs/btrfs/inode.c   |6 --
 3 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs_inode.h
index 71f074e..fbe745e 100644
--- a/fs/btrfs/btrfs_inode.h
+++ b/fs/btrfs/btrfs_inode.h
@@ -19,6 +19,7 @@
 #ifndef __BTRFS_I__
 #define __BTRFS_I__
 
+#include 
 #include "extent_map.h"
 #include "extent_io.h"
 #include "ordered-data.h"
@@ -179,6 +180,25 @@ static inline struct btrfs_inode *BTRFS_I(struct inode 
*inode)
return container_of(inode, struct btrfs_inode, vfs_inode);
 }
 
+static inline unsigned long inode_hash(u64 objectid,
+  const struct btrfs_root *root)
+{
+   u64 h = objectid ^ (root->objectid * GOLDEN_RATIO_PRIME);
+
+#if BITS_PER_LONG == 32
+   h = (h >> 32) ^ (h & 0x);
+#endif
+
+   return (unsigned long)h;
+}
+
+static inline void btrfs_insert_inode_hash(struct inode *inode)
+{
+   unsigned long h = inode_hash(inode->i_ino, BTRFS_I(inode)->root);
+
+   __insert_inode_hash(inode, h);
+}
+
 static inline u64 btrfs_ino(struct inode *inode)
 {
u64 ino = BTRFS_I(inode)->location.objectid;
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index ade6c0e..d205bdd 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -2294,7 +2294,7 @@ int open_ctree(struct super_block *sb,
   sizeof(struct btrfs_key));
set_bit(BTRFS_INODE_DUMMY,
&BTRFS_I(fs_info->btree_inode)->runtime_flags);
-   insert_inode_hash(fs_info->btree_inode);
+   btrfs_insert_inode_hash(fs_info->btree_inode);
 
spin_lock_init(&fs_info->block_group_cache_lock);
fs_info->block_group_cache_tree = RB_ROOT;
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 13b470c..3c76bf4 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -4837,10 +4837,12 @@ static struct inode *btrfs_iget_locked(struct 
super_block *s,
 {
struct inode *inode;
struct btrfs_iget_args args;
+   unsigned long hashval = inode_hash(objectid, root);
+
args.ino = objectid;
args.root = root;
 
-   inode = iget5_locked(s, objectid, btrfs_find_actor,
+   inode = iget5_locked(s, hashval, btrfs_find_actor,
 btrfs_init_locked_inode,
 (void *)&args);
return inode;
@@ -5460,7 +5462,7 @@ static struct inode *btrfs_new_inode(struct 
btrfs_trans_handle *trans,
BTRFS_INODE_NODATASUM;
}
 
-   insert_inode_hash(inode);
+   btrfs_insert_inode_hash(inode);
inode_tree_add(inode);
 
trace_btrfs_inode_new(inode);
-- 
1.7.9.5

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


defrag - kernel BUG at fs/btrfs/locking.c:264!

2013-10-06 Thread David Taylor
Hi,

Whilst running a recursive defrag with -czlib (to compress some files copied 
when I forgot
to mount the filesystem with -o compress=zlib), I encountered the BUG below.  
The
btrfs defrag command then hung, as did other attempts to use the filesystem.  
Shortly afterwards
the entire system locked up.  I think I have encountered this twice now, but 
the first time
the system locked up whilst I was out and I was unable to check dmesg.

This is on linux-3.12-rc3 with up-to-date git btrfs-progs.  I'm also using the 
'experimental'
dedup-syscall git branch of bedup.

[ 7815.359821] [ cut here ]
[ 7815.361458] WARNING: CPU: 3 PID: 3640 at fs/btrfs/locking.c:46 
btrfs_set_lock_blocking_rw+0x6c/0xdc [btrfs]()
[ 7815.362981] Modules linked in: parport_pc bnep rfcomm ppdev bluetooth rfkill 
sp5100_tco i2c_piix4 edac_mce_amd edac_core ehci_pci ohci_pci ohci_hcd ehci_hcd 
serio_raw k10temp evdev acpi_cpufreq asus_atk0110 processor lp parport loop 
btrfs crc32c libcrc32c ext4 crc16 jbd2 mbcache raid456 async_raid6_recov 
async_memcpy async_pq async_xor async_tx xor raid6_pq raid0 multipath linear 
raid1 raid10 md_mod dm_mod sd_mod sr_mod crc_t10dif crct10dif_common cdrom 
ata_generic ahci pata_jmicron libahci firewire_ohci xhci_hcd firewire_core 
libata crc_itu_t scsi_mod usbcore usb_common nouveau mxm_wmi video i2c_algo_bit 
ttm drm_kms_helper r8169 mii drm i2c_core thermal_sys wmi button
[ 7815.368026] CPU: 3 PID: 3640 Comm: btrfs Not tainted 3.12.0-rc3-yadt #1
[ 7815.369613] Hardware name: System manufacturer System Product 
Name/M4A89GTD-PRO/USB3, BIOS 170311/16/2010
[ 7815.371176]   8136c8ad  
8103612b
[ 7815.372759]  a03d3820 8801604a71e0 8801604a71e0 
0001
[ 7815.374424]  880225766000 a03d3820  
8801604a71e0
[ 7815.376026] Call Trace:
[ 7815.377665]  [] ? dump_stack+0x41/0x51
[ 7815.379313]  [] ? warn_slowpath_common+0x74/0x89
[ 7815.380962]  [] ? btrfs_set_lock_blocking_rw+0x6c/0xdc 
[btrfs]
[ 7815.382661]  [] ? btrfs_set_lock_blocking_rw+0x6c/0xdc 
[btrfs]
[ 7815.384332]  [] ? btrfs_realloc_node+0xd0/0x371 [btrfs]
[ 7815.386001]  [] ? btrfs_node_key_to_cpu+0x12/0x30 [btrfs]
[ 7815.387677]  [] ? btrfs_defrag_leaves+0x232/0x2e4 [btrfs]
[ 7815.389359]  [] ? btrfs_defrag_root+0x54/0xb6 [btrfs]
[ 7815.391009]  [] ? btrfs_ioctl_defrag+0x75/0x140 [btrfs]
[ 7815.392627]  [] ? btrfs_ioctl+0x822/0x2030 [btrfs]
[ 7815.394162]  [] ? get_page+0x9/0x25
[ 7815.395650]  [] ? __lru_cache_add+0x1a/0x38
[ 7815.397124]  [] ? handle_mm_fault+0x881/0x8a6
[ 7815.398575]  [] ? __do_page_fault+0x348/0x3e8
[ 7815.400053]  [] ? do_filp_open+0x2b/0x6f
[ 7815.401510]  [] ? vfs_ioctl+0x1b/0x28
[ 7815.402985]  [] ? do_vfs_ioctl+0x3ab/0x3ee
[ 7815.404405]  [] ? SyS_ioctl+0x4e/0x7a
[ 7815.405822]  [] ? system_call_fastpath+0x16/0x1b
[ 7815.407231] ---[ end trace 66d49a7250b29fb0 ]---
[ 7815.408697] [ cut here ]
[ 7815.410077] kernel BUG at fs/btrfs/locking.c:264!
[ 7815.411528] invalid opcode:  [#1] SMP
[ 7815.412935] Modules linked in: parport_pc bnep rfcomm ppdev bluetooth rfkill 
sp5100_tco i2c_piix4 edac_mce_amd edac_core ehci_pci ohci_pci ohci_hcd ehci_hcd 
serio_raw k10temp evdev acpi_cpufreq asus_atk0110 processor lp parport loop 
btrfs crc32c libcrc32c ext4 crc16 jbd2 mbcache raid456 async_raid6_recov 
async_memcpy async_pq async_xor async_tx xor raid6_pq raid0 multipath linear 
raid1 raid10 md_mod dm_mod sd_mod sr_mod crc_t10dif crct10dif_common cdrom 
ata_generic ahci pata_jmicron libahci firewire_ohci xhci_hcd firewire_core 
libata crc_itu_t scsi_mod usbcore usb_common nouveau mxm_wmi video i2c_algo_bit 
ttm drm_kms_helper r8169 mii drm i2c_core thermal_sys wmi button
[ 7815.417766] CPU: 3 PID: 3640 Comm: btrfs Tainted: GW
3.12.0-rc3-yadt #1
[ 7815.419259] Hardware name: System manufacturer System Product 
Name/M4A89GTD-PRO/USB3, BIOS 170311/16/2010
[ 7815.420845] task: 88022565e7b0 ti: 880044268000 task.ti: 
880044268000
[ 7815.422373] RIP: 0010:[]  [] 
btrfs_assert_tree_locked+0x7/0xa [btrfs]
[ 7815.424003] RSP: 0018:880044269c08  EFLAGS: 00010246
[ 7815.425580] RAX:  RBX: 8801604a71e0 RCX: 0007
[ 7815.427161] RDX: 0006 RSI:  RDI: 8801604a71e0
[ 7815.428746] RBP: 8801604a71e0 R08:  R09: 
[ 7815.430279] R10: 8802 R11: 0001205c R12: 0001
[ 7815.431762] R13: 880225766000 R14:  R15: 
[ 7815.433189] FS:  7f878c9ed780() GS:88022fcc() 
knlGS:
[ 7815.434700] CS:  0010 DS:  ES:  CR0: 8005003b
[ 7815.436201] CR2: 0275d868 CR3: 2b9f CR4: 07e0
[ 7815.437696] Stack:
[ 7815.439139]  a03d3831  8801604a71e0 

[ 7815.440600]  a038dc4c 0002

Re: btrfs device delete problem

2013-10-06 Thread Chris Murphy

On Oct 6, 2013, at 5:10 AM, Alfredo Esteban  wrote:
> 
>> btrfs device delete /dev/sdh1 /mnt/raid-data/
> ERROR: error removing the device '/dev/sdh1' - Inappropriate ioctl for device

It's sortof a generic error, I think it's fixed since I haven't seen this 
recently with newer kernels. What do you get in dmesg? Any other messages at 
the time this command was issued?

> 
> Raid has been working fine for a long time. Both devices are present
> but /dev/sdh1 is a new empty btrfs partition at the moment.

>From your post:
>> devid2 size 149.05GB used 109.01GB path /dev/sdh1

109GB used isn't exactly empty.


> I should like to know whether this is an error or "btrfs device
> delete" command is not the appropriate one. I just want to know how to
> delete sdh1 from raid, add a new partition and balance.
> 
> My kernel version is: 3.8.0-31

I'd upgrade the kernel to 3.10.14 or wait for some balance fixes to get into 
3.11.x and the next 3.12 rc.


Chris Murphy--
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 device delete problem

2013-10-06 Thread Alfredo Esteban
Hi,

I'm getting an error when trying to delete a device from a raid1 (data
and metadata mirrored).

> btrfs filesystem show
failed to read /dev/sr0
Label: none  uuid: 78b5162b-489e-4de1-a989-a47b91adef50
Total devices 2 FS bytes used 107.64GB
devid2 size 149.05GB used 109.01GB path /dev/sdh1
devid1 size 156.81GB used 109.03GB path /dev/sdb6

Btrfs v0.20-rc1

> btrfs device delete /dev/sdh1 /mnt/raid-data/
ERROR: error removing the device '/dev/sdh1' - Inappropriate ioctl for device

Raid has been working fine for a long time. Both devices are present
but /dev/sdh1 is a new empty btrfs partition at the moment.

I should like to know whether this is an error or "btrfs device
delete" command is not the appropriate one. I just want to know how to
delete sdh1 from raid, add a new partition and balance.

My kernel version is: 3.8.0-31

Thanks,

Alfredo
--
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: Linux Arch: kernel BUG at fs/btrfs/inode.c:873!

2013-10-06 Thread Duncan
Anatol Pomozov posted on Sat, 05 Oct 2013 22:14:25 -0700 as excerpted:

> Actually I remembered that I set "chattr +C" on /var/log/journal
> recursively (even for non-empty files) about a week ago, it might be
> related to the crash. When I mount "-orw" and try to remove
> /var/log/journal system hangs in btrfs-transacti thread.

Based on what I've seen in other threads and how nocow works, you really 
need to either set it (on the dir) before the files are created, or touch 
them so they're zero size and set it then.  You did say you set it on the 
dir, recursively, but existing files would then have been COW for awhile, 
and that might be related to your problem now, particularly with the just 
freshly patched systemd-journal-file-triggered-bug I mentioned.

Of course as you likely know but others googling this or otherwise 
reading it may not, btrfs is still labeled experimental, and while it 
does work pretty well for the general case, it's exactly the slightly or 
very oddball cases such as allocate-and-write-into technique that isn't 
quite so common, that can still be buggy.  In addition to a few loose-end 
features still being wrapped up, it's finding and fixing stuff like this 
that's the biggest thing still left before btrfs can be labeled stable 
and fully ready for normal and production use.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

--
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: kernel BUG at fs/btrfs/relocation.c:1060 during rebalancing

2013-10-06 Thread cwillu
Another user has just reported this in irc on 3.11.2

kernel BUG at fs/btrfs/relocation.c:1055!
invalid opcode:  [#1] SMP
Modules linked in: ebtable_nat nf_conntrack_netbios_ns
nf_conntrack_broadcast ipt_MASQUERADE ip6table_nat nf_nat_ipv6
ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
iptable_nat nf_nat_ipv4 nf_nat iptable_mangle nf_conntrack_ipv4
nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables bnep
ip6table_filter ip6_tables arc4 x86_pkg_temp_thermal coretemp
kvm_intel ath9k_htc joydev ath9k_common ath9k_hw ath kvm
snd_hda_codec_hdmi mac80211 cfg80211 iTCO_wdt iTCO_vendor_support
ath3k r8169 btusb snd_hda_codec_realtek snd_hda_intel mii
snd_hda_codec snd_hwdep serio_raw snd_seq snd_seq_device mxm_wmi
snd_pcm bluetooth mei_me microcode i2c_i801 rfkill shpchp lpc_ich
mfd_core mei wmi mperf snd_page_alloc snd_timer snd soundcore uinput
btrfs libcrc32c xor zlib_deflate raid6_pq dm_crypt hid_logitech_dj
i915 crc32_pclmul crc32c_intel ghash_clmulni_intel i2c_algo_bit
drm_kms_helper drm i2c_core video
CPU: 1 PID: 564 Comm: btrfs-balance Not tainted 3.11.2-201.fc19.x86_64 #1
Hardware name: ECS Z77H2-AX/Z77H2-AX, BIOS 4.6.5 10/25/2012
task: 8807ee1c1e80 ti: 8807f1cc8000 task.ti: 8807f1cc8000
RIP: 0010:[]  []
build_backref_tree+0x1077/0x1130 [btrfs]
RSP: 0018:8807f1cc9ab8  EFLAGS: 00010246
RAX:  RBX: 8807eef77480 RCX: dead00200200
RDX: 8807f1cc9b28 RSI: 8807f1cc9b28 RDI: 8807ef5896d0
RBP: 8807f1cc9b98 R08: 8807ef5896d0 R09: 0001
R10: a01f5483 R11:  R12: 8807ef5896d0
R13: 8807ef5896c0 R14: 8807f22ee360 R15: 8807f0e62000
FS:  () GS:88081f24() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f7d97749a90 CR3: 0007e38ef000 CR4: 001407e0
Stack:
 8807f0e62580 8807eef77a80 8807ef5899e0 8807eef77780
 8807ea5ab000 8807f22ee360 8807eef777c0 8807f22ee000
 8807f0e62120 8807eef77a80 8807f0e62020 
Call Trace:
 [] relocate_tree_blocks+0x1d8/0x630 [btrfs]
 [] ? add_data_references+0x248/0x280 [btrfs]
 [] relocate_block_group+0x280/0x690 [btrfs]
 [] btrfs_relocate_block_group+0x19f/0x2e0 [btrfs]
 [] btrfs_relocate_chunk.isra.32+0x6f/0x740 [btrfs]
 [] ? btrfs_set_path_blocking+0x39/0x80 [btrfs]
 [] ? btrfs_search_slot+0x382/0x940 [btrfs]
 [] ? free_extent_buffer+0x4f/0xa0 [btrfs]
 [] btrfs_balance+0x8e7/0xe80 [btrfs]
 [] balance_kthread+0x70/0x80 [btrfs]
 [] ? btrfs_balance+0xe80/0xe80 [btrfs]
 [] kthread+0xc0/0xd0
 [] ? insert_kthread_work+0x40/0x40
 [] ret_from_fork+0x7c/0xb0
 [] ? insert_kthread_work+0x40/0x40
Code: 4c 89 f7 e8 0c 0c f9 ff 48 8b bd 58 ff ff ff e8 00 0c f9 ff 48
83 bd 38 ff ff ff 00 0f 85 1e fe ff ff 31 c0 e9 5d f0 ff ff 0f 0b <0f>
0b 48 8b 73 18 48 89 c7 e8 49 f3 01 00 48 8b 85 38 ff ff ff
RIP  [] build_backref_tree+0x1077/0x1130 [btrfs]
 RSP 

On Wed, Sep 25, 2013 at 11:26 PM, Guenther Starnberger
 wrote:
> On Wed, Sep 25, 2013 at 04:46:41PM +0200, David Sterba wrote:
>
>> 3.12-rc really? I'd like to see the stacktrace then.
>
> Yes - this also happens on 3.12-rc kernels. Here's the stacktrace for 4b97280
> (which is several commits ahead of 3.12-rc2):
>
> [  126.735598] btrfs: disk space caching is enabled
> [  126.737038] btrfs: has skinny extents
> [  144.769929] BTRFS debug (device dm-0): unlinked 1 orphans
> [  144.836240] btrfs: continuing balance
> [  153.441134] btrfs: relocating block group 1542996361216 flags 1
> [  295.780293] btrfs: found 18 extents
> [  310.107200] [ cut here ]
> [  310.108496] kernel BUG at fs/btrfs/relocation.c:1060!
> [  310.109709] invalid opcode:  [#1] PREEMPT SMP
> [  310.110268] Modules linked in: btrfs raid6_pq crc32c libcrc32c xor xts 
> gf128mul dm_crypt dm_mod usb_storage psmouse ppdev e1000 evdev pcspkr 
> serio_raw joydev microcode snd_intel8x0 snd_ac97_codec i2c_piix4 i2c_core 
> ac97_bus snd_pcm snd_page_alloc snd_timer parport_pc parport snd soundcore 
> intel_agp button battery processor ac intel_gtt ext4 crc16 mbcache jbd2 
> hid_generic usbhid hid sr_mod cdrom sd_mod ata_generic pata_acpi ohci_pci 
> ata_piix ahci libahci ohci_hcd ehci_pci ehci_hcd usbcore usb_common libata 
> scsi_mod
> [  310.110268] CPU: 0 PID: 366 Comm: btrfs-balance Not tainted 
> 3.12.0-1-00083-g4b97280-dirty #1
> [  310.110268] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS 
> VirtualBox 12/01/2006
> [  310.110268] task: 880078b0 ti: 880078afe000 task.ti: 
> 880078afe000
> [  310.110268] RIP: 0010:[]  [] 
> build_backref_tree+0x112a/0x11d0 [btrfs]
> [  310.110268] RSP: 0018:880078affab8  EFLAGS: 00010246
> [  310.110268] RAX:  RBX: 8800784d4000 RCX: 
> 88006a2a9d90
> [  310.110268] RDX: 880078affb30 RSI: 8800784d4020 RDI: 
> 88006a2a9d80
> [  310.110268] RBP: 880078affba0 R08: 880077d07e00 R09: 
> 880078affa