btrfs and mainline and git
Hello, 1. I normally copy btrfs into the mainline and run make, however with the recent btrfs release its failing with the following, any idea. ? - # make scripts/kconfig/conf --silentoldconfig Kconfig fs/btrfs/Kconfig:6: syntax error fs/Kconfig:9: missing end statement for this entry fs/Kconfig:5: missing end statement for this entry fs/btrfs/Kconfig:5: invalid statement arch/x86/Kconfig:253: recursive inclusion detected. Inclusion path: current file : 'arch/x86/Kconfig' included from: 'fs/btrfs/Kconfig:11' included from: 'fs/Kconfig:36' included from: 'arch/x86/Kconfig:2145' make[2]: *** [silentoldconfig] Error 1 make[1]: *** [silentoldconfig] Error 2 make: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'. Stop. # - 2. Looks like the official way is to use git merge. What are the recommended git (merge ?) steps, to integrate btrfs into the mainline ? Thanks for your time, -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: git resources
On 19.08.2011 09:09, Anand Jain wrote: Hello, There are quite a number of contents on the internet talking about git. (a problem in my case). Since I just need one good providing steps for what we are doing here.. You should take the time and learn git properly. I can recommend Version Control with Git by Jon Loeliger. --- clone mainline clone btrfs (or some other) merge (make menuconfig, make, make modules_install, make install) make change(s) generate patch(s) setup for thunderbird send-email setup send-mail with the patches in the body make change(s) again generate patch(s) again send-mail pull the newer official release when released. apply the patch --- any idea what can help ? Appreciate your time. (When we have this I shall update the btrfs wiki) 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: Applications using fsync cause hangs for several seconds every few minutes
On 18/08/11 16:58, youagree wrote: Are these processes principally btrfs-submit and btrfs-transacti in particular? Then it may be related to my very similar issue reported earlier. I spent a little bit of time last night looking at it and it seems that what I'm seeing also affects ext4 on my local SATA mirror too, so whatever is going on doesn't appear to be related to btrfs. So ignore my comment.. ;-) cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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: processes stuck in llseek
Here it is. http://marc.info/?l=linux-btrfsm=131176036219732w=2 That was it, thanks. Confirmed fixed. -- 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
bonnie triggers and endless numbers of stack traces
Just for performance tests I run:
./bonnie++ -d /mnt/btrfs -s0 -n 1:256:256:1 -r 0
and this causes and endless number of stack traces. Those seem to
come from:
use_block_rsv()
ret = block_rsv_use_bytes(block_rsv, blocksize);
if (!ret)
return block_rsv;
if (ret) {
WARN_ON(1);
ret = reserve_metadata_bytes(trans, root, block_rsv, blocksize,
Why is there a WARN_ON(1)? Running the bonnie benchmark is basically impossible
that.
Thanks,
Bernd
Aug 19 18:30:56 fslab2 kernel: [ 265.255644] Loglevel set to 9
Aug 19 18:31:26 fslab2 kernel: [ 295.490858] [ cut here
]
Aug 19 18:31:26 fslab2 kernel: [ 295.495589] WARNING: at
fs/btrfs/extent-tree.c:5711 btrfs_alloc_free_block+0x200/0x360 [btrfs]()
Aug 19 18:31:26 fslab2 kernel: [ 295.504472] Hardware name: H8DCE
Aug 19 18:31:26 fslab2 kernel: [ 295.507750] Modules linked in: nfsd ib_umad
rdma_ucm rdma_cm iw_cm ib_addr ib_uverbs sg ib_ipoib ib_cm ib_sa ip
v6 sd_mod crc_t10dif loop arcmsr md_mod ib_mthca ib_mad pcspkr ib_core
8250_pnp fuse af_packet nfs lockd fscache auth_rpcgss nfs_acl sunrpc btrfs
lzo_decompress lzo_compress zlib_deflate crc32c libcrc32c crypto_hash
crypto_algapi ata_generic pata_acpi e1000 pata_amd sata_nv libata scsi_mod
unix [last unloaded: scsi_wait_scan]
Aug 19 18:31:26 fslab2 kernel: [ 295.548618] Pid: 2074, comm: bonnie++ Not
tainted 3.1.0-rc2+ #34
Aug 19 18:31:26 fslab2 kernel: [ 295.554695] Call Trace:
Aug 19 18:31:26 fslab2 kernel: [ 295.557209] [8105c677] ?
console_unlock+0x227/0x290
Aug 19 18:31:26 fslab2 kernel: [ 295.563111] [8105bb7f]
warn_slowpath_common+0x7f/0xc0
Aug 19 18:31:26 fslab2 kernel: [ 295.569186] [8105bbda]
warn_slowpath_null+0x1a/0x20
Aug 19 18:31:26 fslab2 kernel: [ 295.575096] [a013d0d0]
btrfs_alloc_free_block+0x200/0x360 [btrfs]
Aug 19 18:31:26 fslab2 kernel: [ 295.582230] [a0165d10] ?
lock_delalloc_pages+0x1f0/0x1f0 [btrfs]
Aug 19 18:31:26 fslab2 kernel: [ 295.589280] [a0127b6b]
__btrfs_cow_block+0x14b/0x6e0 [btrfs]
Aug 19 18:31:26 fslab2 kernel: [ 295.595978] [a0179144] ?
btrfs_try_tree_write_lock+0x44/0x80 [btrfs]
Aug 19 18:31:26 fslab2 kernel: [ 295.603394] [a0128217]
btrfs_cow_block+0x117/0x260 [btrfs]
Aug 19 18:31:26 fslab2 kernel: [ 295.609920] [a012e455]
btrfs_search_slot+0x385/0xaa0 [btrfs]
Aug 19 18:31:26 fslab2 kernel: [ 295.616621] [a0140f3f]
btrfs_lookup_inode+0x2f/0xa0 [btrfs]
Aug 19 18:31:26 fslab2 kernel: [ 295.623236] [a0190eb3]
btrfs_update_delayed_inode+0x73/0x160 [btrfs]
Aug 19 18:31:26 fslab2 kernel: [ 295.630644] [8137163e] ?
mutex_unlock+0xe/0x10
Aug 19 18:31:26 fslab2 kernel: [ 295.636125] [a0192088]
btrfs_run_delayed_items+0xe8/0x120 [btrfs]
Aug 19 18:31:26 fslab2 kernel: [ 295.643254] [a014a240]
btrfs_commit_transaction+0x230/0x870 [btrfs]
Aug 19 18:31:26 fslab2 kernel: [ 295.650585] [a0149de9] ?
join_transaction+0x69/0x290 [btrfs]
Aug 19 18:31:26 fslab2 kernel: [ 295.657274] [8107f410] ?
wake_up_bit+0x40/0x40
Aug 19 18:31:26 fslab2 kernel: [ 295.662783] [81171700] ?
__sync_filesystem+0x90/0x90
Aug 19 18:31:26 fslab2 kernel: [ 295.668783] [a0124ace]
btrfs_sync_fs+0x5e/0xd0 [btrfs]
Aug 19 18:31:26 fslab2 kernel: [ 295.674951] [811716ce]
__sync_filesystem+0x5e/0x90
Aug 19 18:31:26 fslab2 kernel: [ 295.680764] [8117171f]
sync_one_sb+0x1f/0x30
Aug 19 18:31:26 fslab2 kernel: [ 295.686061] [8114751f]
iterate_supers+0x7f/0xe0
Aug 19 18:31:26 fslab2 kernel: [ 295.691613] [81171775]
sys_sync+0x45/0x70
Aug 19 18:31:26 fslab2 kernel: [ 295.696648] [8137b4c2]
system_call_fastpath+0x16/0x1b
Aug 19 18:31:26 fslab2 kernel: [ 295.702726] ---[ end trace 5328a9730b4cdff4
]---
Aug 19 18:31:26 fslab2 kernel: [ 295.707533] [ cut here
]
Aug 19 18:31:26 fslab2 kernel: [ 295.712230] WARNING: at
fs/btrfs/extent-tree.c:5711 btrfs_alloc_free_block+0x200/0x360 [btrfs]()
Aug 19 18:31:26 fslab2 kernel: [ 295.721114] Hardware name: H8DCE
Aug 19 18:31:26 fslab2 kernel: [ 295.724410] Modules linked in: nfsd ib_umad
rdma_ucm rdma_cm iw_cm ib_addr ib_uverbs sg ib_ipoib ib_cm ib_sa ip
v6 sd_mod crc_t10dif loop arcmsr md_mod ib_mthca ib_mad pcspkr ib_core
8250_pnp fuse af_packet nfs lockd fscache auth_rpcgss nfs_acl sunrpc btrfs
lzo_decompress lzo_compress zlib_deflate crc32c libcrc32c crypto_hash
crypto_algapi ata_generic pata_acpi e1000 pata_amd sata_nv libata scsi_mod
[...]
repeats at least a few thousand times and fills the logs...
--
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: bonnie triggers and endless numbers of stack traces
I think we either should remove it or replace by WARN_ON_ONCE()
Remove WARN_ON(1) in a common code path
From: Bernd Schubert bernd.schub...@itwm.fraunhofer.de
Something like bonnie++ -d /mnt/btrfs -s0 -n 1:256:256:1 -r 0
will trigger lots of those WARN_ON(1), so lets remove it.
Signed-off-by: Bernd Schubert bernd.schub...@itwm.fraunhofer.de
---
fs/btrfs/extent-tree.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 80d6148..1d1a8d0 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -5708,7 +5708,6 @@ use_block_rsv(struct btrfs_trans_handle *trans,
if (!ret)
return block_rsv;
if (ret) {
- WARN_ON(1);
ret = reserve_metadata_bytes(trans, root, block_rsv, blocksize,
0);
if (!ret) {
--
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: bonnie triggers and endless numbers of stack traces
On 08/19/2011 12:45 PM, Bernd Schubert wrote:
Just for performance tests I run:
./bonnie++ -d /mnt/btrfs -s0 -n 1:256:256:1 -r 0
and this causes and endless number of stack traces. Those seem to
come from:
use_block_rsv()
ret = block_rsv_use_bytes(block_rsv, blocksize);
if (!ret)
return block_rsv;
if (ret) {
WARN_ON(1);
ret = reserve_metadata_bytes(trans, root, block_rsv, blocksize,
Why is there a WARN_ON(1)? Running the bonnie benchmark is basically
impossible
that.
This is being worked on, if you really don't like it pull my git tree
and test it out and see if the errors go away
git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-work.git
Thanks,
Josef
--
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: only reserve space in fallocate if we have to do a preallocate
Lukas found a problem where if he tries to fallocate over the same region twice
and the first fallocate took up all the space we would fail with ENOSPC. This
is because we reserve the total space we want to use for fallocate, regardless
of wether or not we will have to actually preallocate. So instead move the
check into the loop where we actually have to do the preallocate. Thanks,
Tested-by: Lukas Czerner lczer...@redhat.com
Signed-off-by: Josef Bacik jo...@redhat.com
---
fs/btrfs/file.c | 22 --
1 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index e7872e4..4cd3329 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -1603,10 +1603,6 @@ static long btrfs_fallocate(struct file *file, int mode,
goto out;
}
- ret = btrfs_check_data_free_space(inode, alloc_end - alloc_start);
- if (ret)
- goto out;
-
locked_end = alloc_end - 1;
while (1) {
struct btrfs_ordered_extent *ordered;
@@ -1652,11 +1648,27 @@ static long btrfs_fallocate(struct file *file, int mode,
if (em-block_start == EXTENT_MAP_HOLE ||
(cur_offset = inode-i_size
!test_bit(EXTENT_FLAG_PREALLOC, em-flags))) {
+
+ /*
+* Make sure we have enough space before we do the
+* allocation.
+*/
+ ret = btrfs_check_data_free_space(inode, last_byte -
+ cur_offset);
+ if (ret) {
+ free_extent_map(em);
+ break;
+ }
+
ret = btrfs_prealloc_file_range(inode, mode, cur_offset,
last_byte - cur_offset,
1 inode-i_blkbits,
offset + len,
alloc_hint);
+
+ /* Let go of our reservation. */
+ btrfs_free_reserved_data_space(inode, last_byte -
+ cur_offset);
if (ret 0) {
free_extent_map(em);
break;
@@ -1682,8 +1694,6 @@ static long btrfs_fallocate(struct file *file, int mode,
}
unlock_extent_cached(BTRFS_I(inode)-io_tree, alloc_start, locked_end,
cached_state, GFP_NOFS);
-
- btrfs_free_reserved_data_space(inode, alloc_end - alloc_start);
out:
mutex_unlock(inode-i_mutex);
return ret;
--
1.7.5.2
--
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: reduce the amount of space needed for truncates
With btrfs_truncate_inode_items we always return if we have to go to another
leaf, which makes us do our reservation again. This means we will only ever
modify one leaf at a time, so we only need 1 items worth of slack space. Also,
since we are deleting we will not be creating nodes as we go down, if anything
we'll be free'ing them as we merge them together, so make a different
calculation for truncate which will only have the worst case useage of COW'ing
the entire path down to the leaf. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
fs/btrfs/ctree.h | 11 +++
fs/btrfs/inode.c |8
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 22a9347..2e18b06 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -2125,6 +2125,17 @@ static inline u64 btrfs_calc_trans_metadata_size(struct
btrfs_root *root,
3 * num_items;
}
+/*
+ * Doing a truncate won't result in new nodes or leaves, just what we need for
+ * COW.
+ */
+static inline u64 btrfs_calc_trunc_metadata_size(struct btrfs_root *root,
+unsigned num_items)
+{
+ return (root-leafsize + root-nodesize * (BTRFS_MAX_LEVEL - 1)) *
+ num_items;
+}
+
void btrfs_put_block_group(struct btrfs_block_group_cache *cache);
int btrfs_run_delayed_refs(struct btrfs_trans_handle *trans,
struct btrfs_root *root, unsigned long count);
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 217b669..e8d67db 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -3524,7 +3524,7 @@ void btrfs_evict_inode(struct inode *inode)
struct btrfs_trans_handle *trans;
struct btrfs_root *root = BTRFS_I(inode)-root;
struct btrfs_block_rsv *rsv;
- u64 min_size = btrfs_calc_trans_metadata_size(root, 2);
+ u64 min_size = btrfs_calc_trunc_metadata_size(root, 1);
unsigned long nr;
int ret;
@@ -6471,7 +6471,7 @@ static int btrfs_truncate(struct inode *inode)
struct btrfs_trans_handle *trans;
unsigned long nr;
u64 mask = root-sectorsize - 1;
- u64 min_size = btrfs_calc_trans_metadata_size(root, 2);
+ u64 min_size = btrfs_calc_trunc_metadata_size(root, 1);
ret = btrfs_truncate_page(inode-i_mapping, inode-i_size);
if (ret)
@@ -6521,12 +6521,12 @@ static int btrfs_truncate(struct inode *inode)
return -ENOMEM;
/*
-* 2 for the truncate slack space
+* 1 for the truncate slack space
* 1 for the orphan item we're going to add
* 1 for the orphan item deletion
* 1 for updating the inode.
*/
- trans = btrfs_start_transaction(root, 5);
+ trans = btrfs_start_transaction(root, 4);
if (IS_ERR(trans)) {
err = PTR_ERR(trans);
goto out;
--
1.7.5.2
--
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: allow callers to specify if flushing can occur for btrfs_block_rsv_check
If you run xfstest 224 it you will get lots of messages about not being able to
delete inodes and that they will be cleaned up next mount. This is because
btrfs_block_rsv_check was not calling reserve_metadata_bytes with the ability to
flush, so if there was not enough space, it simply failed. But in truncate and
evict case we could easily flush space to try and get enough space to do our
work, so make btrfs_block_rsv_check take a flush argument to pass down to
reserve_metadata_bytes. Now xfstests 224 runs fine without all those
complaints. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
fs/btrfs/ctree.h|2 +-
fs/btrfs/extent-tree.c |4 ++--
fs/btrfs/free-space-cache.c |2 +-
fs/btrfs/inode.c|6 +++---
fs/btrfs/relocation.c |4 ++--
fs/btrfs/transaction.c |2 +-
6 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 2e18b06..caa73cd 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -2244,7 +2244,7 @@ int btrfs_block_rsv_add(struct btrfs_trans_handle *trans,
int btrfs_block_rsv_check(struct btrfs_trans_handle *trans,
struct btrfs_root *root,
struct btrfs_block_rsv *block_rsv,
- u64 min_reserved, int min_factor);
+ u64 min_reserved, int min_factor, int flush);
int btrfs_block_rsv_migrate(struct btrfs_block_rsv *src_rsv,
struct btrfs_block_rsv *dst_rsv,
u64 num_bytes);
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index e42f2b6..4075fd1 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -3705,7 +3705,7 @@ int btrfs_block_rsv_add(struct btrfs_trans_handle *trans,
int btrfs_block_rsv_check(struct btrfs_trans_handle *trans,
struct btrfs_root *root,
struct btrfs_block_rsv *block_rsv,
- u64 min_reserved, int min_factor)
+ u64 min_reserved, int min_factor, int flush)
{
u64 num_bytes = 0;
int ret = -ENOSPC;
@@ -3728,7 +3728,7 @@ int btrfs_block_rsv_check(struct btrfs_trans_handle
*trans,
if (!ret)
return 0;
- ret = reserve_metadata_bytes(trans, root, block_rsv, num_bytes, 0);
+ ret = reserve_metadata_bytes(trans, root, block_rsv, num_bytes, flush);
if (!ret) {
block_rsv_add_bytes(block_rsv, num_bytes, 0);
return 0;
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index 8a391bd..d6c4dab 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -197,7 +197,7 @@ int btrfs_truncate_free_space_cache(struct btrfs_root *root,
trans-block_rsv = root-orphan_block_rsv;
ret = btrfs_block_rsv_check(trans, root,
root-orphan_block_rsv,
- 0, 5);
+ 0, 5, 0);
if (ret)
return ret;
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index e8d67db..6e79a76 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -3572,10 +3572,10 @@ void btrfs_evict_inode(struct inode *inode)
* doing the truncate.
*/
while (1) {
- ret = btrfs_block_rsv_check(NULL, root, rsv, min_size, 0);
+ ret = btrfs_block_rsv_check(NULL, root, rsv, min_size, 0, 1);
if (ret) {
printk(KERN_WARNING Could not get space for a
- delete, will truncate on mount\n);
+ delete, will truncate on mount %d\n, ret);
btrfs_orphan_del(NULL, inode);
btrfs_free_block_rsv(root, rsv);
goto no_delete;
@@ -6564,7 +6564,7 @@ static int btrfs_truncate(struct inode *inode)
btrfs_add_ordered_operation(trans, root, inode);
while (1) {
- ret = btrfs_block_rsv_check(trans, root, rsv, min_size, 0);
+ ret = btrfs_block_rsv_check(trans, root, rsv, min_size, 0, 1);
if (ret) {
/*
* This can only happen with the original transaction we
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index aeaed99..fd9ac66 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -2042,7 +2042,7 @@ static noinline_for_stack int merge_reloc_root(struct
reloc_control *rc,
trans-block_rsv = rc-block_rsv;
ret = btrfs_block_rsv_check(trans, root, rc-block_rsv,
- min_reserved, 0);
+ min_reserved, 0, 0);
if (ret) {
BUG_ON(ret != -EAGAIN);
ret = btrfs_commit_transaction(trans, root);
@@ -3775,7
[PATCH] Btrfs: fix call to btrfs_search_slot in free space cache
We are setting ins_len to 1 even tho we are just modifying an item that should
be there already. This may cause the search stuff to split nodes on the way
down needelessly. Set this to 0 since we aren't inserting anything. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
fs/btrfs/free-space-cache.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index d6c4dab..7912380 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -798,7 +798,7 @@ int __btrfs_write_out_cache(struct btrfs_root *root, struct
inode *inode,
key.offset = offset;
key.type = 0;
- ret = btrfs_search_slot(trans, root, key, path, 1, 1);
+ ret = btrfs_search_slot(trans, root, key, path, 0, 1);
if (ret 0) {
ret = -1;
clear_extent_bit(BTRFS_I(inode)-io_tree, 0, bytes - 1,
--
1.7.5.2
--
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: fix space leak when we fail to make an allocation
When changing back to using a spin_lock to protect the extent counters I decided
that since we would only be dropping our original extent, it was ok to just drop
the extent and return. However since somebody else could have come in and done
a reservation, we need to do the normal song and dance to clear the reservation
out properly. So calculate how much space we need to free, and then subtract
what we just attempted to reserve. If it's more then we know we need to drop
those bytes from the delalloc block rsv. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
fs/btrfs/extent-tree.c | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 4075fd1..44a3107 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -4025,16 +4025,24 @@ int btrfs_delalloc_reserve_metadata(struct inode
*inode, u64 num_bytes)
ret = reserve_metadata_bytes(NULL, root, block_rsv, to_reserve, 1);
if (ret) {
+ u64 to_free = 0;
unsigned dropped;
- /*
-* We don't need the return value since our reservation failed,
-* we just need to clean up our counter.
-*/
+
spin_lock(BTRFS_I(inode)-lock);
dropped = drop_outstanding_extent(inode);
- WARN_ON(dropped 1);
- BTRFS_I(inode)-csum_bytes -= num_bytes;
+ to_free = calc_csum_metadata_size(inode, num_bytes, 0);
spin_unlock(BTRFS_I(inode)-lock);
+ to_free += btrfs_calc_trans_metadata_size(root, dropped);
+
+ /*
+* Somebody could have come in and twiddled with the
+* reservation, so if we have to free more than we would have
+* reserved from this reservation go ahead and release those
+* bytes.
+*/
+ to_free -= to_reserve;
+ if (to_free)
+ btrfs_block_rsv_release(root, block_rsv, to_free);
return ret;
}
--
1.7.5.2
--
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: git resources
On Fri, 2011-08-19 at 12:24 +0100, Hugo Mills wrote: On Fri, Aug 19, 2011 at 09:22:38AM +0200, Arne Jansen wrote: On 19.08.2011 09:09, Anand Jain wrote: Hello, There are quite a number of contents on the internet talking about git. (a problem in my case). Since I just need one good providing steps for what we are doing here.. You should take the time and learn git properly. I can recommend Version Control with Git by Jon Loeliger. Pro Git by Scott Chacon from APress was what I used. I found it very helpful. (I originally got it free as a review copy, but had to hand it on to someone else. So I bought it for myself.) Hugo. http://progit.org/book/ -- Homer Parker hpar...@homershut.net -- 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: bonnie triggers and endless numbers of stack traces
On Fri, Aug 19, 2011 at 03:36:55PM -0400, Josef Bacik wrote: This is being worked on, if you really don't like it pull my git tree and test it out and see if the errors go away git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-work.git pulled on top of latest linus', with top commit: Btrfs: fix space leak when we fail to make an allocation but I still see it, xfstests/013. david -- 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: Free inode mutex on lseek error
From: Andi Kleen a...@linux.intel.com
Introduced with b26751575a9aa55fd6dbf3febde3ff06dfadc44f
Cc: jo...@redhat.com
Cc: chris.ma...@oracle.com
Signed-off-by: Andi Kleen a...@linux.intel.com
---
fs/btrfs/file.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index 658d669..8791613 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -1798,16 +1798,15 @@ static loff_t btrfs_file_llseek(struct file *file,
loff_t offset, int origin)
case SEEK_DATA:
case SEEK_HOLE:
ret = find_desired_extent(inode, offset, origin);
- if (ret) {
- mutex_unlock(inode-i_mutex);
- return ret;
- }
+ if (ret)
+ goto error;
}
+ ret = -EINVAL;
if (offset 0 !(file-f_mode FMODE_UNSIGNED_OFFSET))
- return -EINVAL;
+ goto error;
if (offset inode-i_sb-s_maxbytes)
- return -EINVAL;
+ goto error;
/* Special lock needed here? */
if (offset != file-f_pos) {
@@ -1817,6 +1816,9 @@ static loff_t btrfs_file_llseek(struct file *file, loff_t
offset, int origin)
out:
mutex_unlock(inode-i_mutex);
return offset;
+error:
+ mutex_unlock(inode-i_mutex);
+ return ret;
}
const struct file_operations btrfs_file_operations = {
--
1.7.4.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] Btrfs: use do_div to avoid compile errors on 32bit box
When doing div operation of u64 type, we need to be careful and use do_div
to avoid compile ERROR on 32bit box:
ERROR: __udivdi3 [fs/btrfs/btrfs.ko] undefined!
make[1]: *** [__modpost] Error 1
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
fs/btrfs/extent-tree.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 80d6148..9b495ce 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -6796,14 +6796,14 @@ int btrfs_can_relocate(struct btrfs_root *root, u64
bytenr)
index = get_block_group_index(block_group);
if (index == 0) {
dev_min = 4;
- min_free /= 2;
+ do_div(min_free, 2);
} else if (index == 1) {
dev_min = 2;
} else if (index == 2) {
min_free *= 2;
} else if (index == 3) {
dev_min = fs_devices-rw_devices;
- min_free /= dev_min;
+ do_div(min_free, dev_min);
}
mutex_lock(root-fs_info-chunk_mutex);
--
1.6.5.2
--
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: use do_div to avoid compile errors on 32bit box
On 08/19/2011 09:22 PM, Josef Bacik wrote: On Fri, Aug 19, 2011 at 05:48:44PM +0800, Liu Bo wrote: When doing div operation of u64 type, we need to be careful and use do_div to avoid compile ERROR on 32bit box: ERROR: __udivdi3 [fs/btrfs/btrfs.ko] undefined! make[1]: *** [__modpost] Error 1 Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com Chris just left for vacation, can you send this to Linus/lkml so it gets pulled in. Thanks, Already done. thanks, liubo Josef -- 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] Btrfs: use do_div to avoid compile errors on 32bit box
On 08/20/2011 09:34 AM, Liu Bo wrote:
When doing div operation of u64 type, we need to be careful and use do_div
to avoid compile ERROR on 32bit box:
ERROR: __udivdi3 [fs/btrfs/btrfs.ko] undefined!
make[1]: *** [__modpost] Error 1
Sorry, guys, I just sent a wrong version.
Plz ignore this one. I'm sorry.
thanks,
liubo
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
fs/btrfs/extent-tree.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 80d6148..9b495ce 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -6796,14 +6796,14 @@ int btrfs_can_relocate(struct btrfs_root *root, u64
bytenr)
index = get_block_group_index(block_group);
if (index == 0) {
dev_min = 4;
- min_free /= 2;
+ do_div(min_free, 2);
} else if (index == 1) {
dev_min = 2;
} else if (index == 2) {
min_free *= 2;
} else if (index == 3) {
dev_min = fs_devices-rw_devices;
- min_free /= dev_min;
+ do_div(min_free, dev_min);
}
mutex_lock(root-fs_info-chunk_mutex);
--
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: use do_div to avoid compile errors on 32bit box
When doing div operation of u64 type, we need to be careful and use do_div
to avoid compile ERROR on 32bit box:
ERROR: __udivdi3 [fs/btrfs/btrfs.ko] undefined!
make[1]: *** [__modpost] Error 1
v1-v2:
- fix stupid do_div() with type signed integer.
Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com
---
fs/btrfs/extent-tree.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 80d6148..e43e4f1 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -6735,9 +6735,10 @@ int btrfs_can_relocate(struct btrfs_root *root, u64
bytenr)
struct btrfs_fs_devices *fs_devices = root-fs_info-fs_devices;
struct btrfs_device *device;
u64 min_free;
+ u32 dev_min = 1;
+ u32 dev_nr = 0;
+ u32 dup = 2;
int index;
- int dev_nr = 0;
- int dev_min = 1;
int full = 0;
int ret = 0;
@@ -6796,14 +6797,14 @@ int btrfs_can_relocate(struct btrfs_root *root, u64
bytenr)
index = get_block_group_index(block_group);
if (index == 0) {
dev_min = 4;
- min_free /= 2;
+ do_div(min_free, dup);
} else if (index == 1) {
dev_min = 2;
} else if (index == 2) {
- min_free *= 2;
+ min_free *= dup;
} else if (index == 3) {
dev_min = fs_devices-rw_devices;
- min_free /= dev_min;
+ do_div(min_free, dev_min);
}
mutex_lock(root-fs_info-chunk_mutex);
--
1.6.5.2
--
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 oops - no mount (different problem than others)
Thanks for your help, but unfortunately, it wouldn't mount read-only, either. If you can think of anything else I could try, it would be greatly appreciated! Thanks! - Liam On Thu, Aug 18, 2011 at 8:52 PM, cwillu cwi...@cwillu.com wrote: You might try mounting it -o ro as a stopgap to regain readonly access. Judging from the bootlog, the error itself appears to be enospc. In which case there's no already-available quick fix; I expect a developer to chime in any second now :p From the logs it is listing a transid error but NOT that it is expecting a different one, simply device label 1TB devid 1 transid 248472 /dev/sdb That particular line is the normal listing of devices, which is expected and completely normal. -- 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
