Displaying 20 results from an estimated 200 matches similar to: "[PATCH] Btrfs: fix how we reserve space for deleting inodes"
2013 Aug 19
11
[RFC PATCH] Btrfs: fix memory leak of orphan block rsv
When adding orphans to an inode''s root, we start a transaction for
that root that when ended in several places such as for example
extent-tree.c:btrfs_remove_block_group(), inode.c:btrfs_unlink() and
inode.c:btrfs_evict_node(), doesn''t result in a commit, that is,
inode.c:btrfs_orphan_commit_root() doesn''t get called (via
transaction.c:commit_fs_roots()).
The respective
2011 Jun 08
1
[PATCH] Btrfs: use join_transaction in btrfs_evict_inode()
The WARN_ON() in start_transaction() was triggered while balancing.
The cause is btrfs_relocate_chunk() started a transaction and
then called iput() on the inode that stores free space cache,
and iput() called btrfs_start_transaction() again.
Reported-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
---
fs/btrfs/inode.c | 2 +-
1 files
2012 Jan 05
4
[RFC][PATCH 3/3] Btrfs: improve truncation of btrfs
The original truncation of btrfs has a bug, that is the orphan item will not be
dropped when the truncation fails. This bug will trigger BUG() when unlink that
truncated file. And besides that, if the user does pre-allocation for the file
which is truncated unsuccessfully, after re-mount(umount-mount, not -o remount),
the pre-allocated extent will be dropped.
This patch modified the relative
2011 Dec 02
3
[PATCH] Btrfs: protect orphan block rsv with spin_lock
We''ve been seeing warnings coming out of the orphan commit stuff forever from
ceph. Turns out it''s because we''re racing with checking if the orphan block
reserve is set, because we clear it outside of the spin_lock. So leave the
normal fastpath checks where they are, but take the spin_lock and _recheck_ to
make sure we haven''t had an orphan block rsv added in
2010 Sep 03
0
[PATCH 1/2] btrfs: document where we use BUG_ON instead of error handling
Document those places in the btrfs code which are BUGing on non-fatal error
conditions that should be handled by proper error paths. This makes it
easier to distinguish between what needs fixing versus which BUG_ON''s we
might want to keep (to trap code bugs, unexpected inconsistencies, etc).
Do this with a trivial macro, ''btrfs_fixable_bug_on'' which just defines to
2010 Apr 19
0
[PATCH 08/12] Btrfs: Introduce global metadata reservation
Reserve metadata space for extent tree, checksum tree and root tree
Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
---
diff -urp 8/fs/btrfs/ctree.h 9/fs/btrfs/ctree.h
--- 8/fs/btrfs/ctree.h 2010-04-18 10:26:38.327697818 +0800
+++ 9/fs/btrfs/ctree.h 2010-04-18 10:30:01.883697869 +0800
@@ -682,21 +682,15 @@ struct btrfs_space_info {
u64 bytes_reserved; /* total bytes the allocator has
2011 Jun 09
2
[PATCH] Btrfs: turn to readonly if btrfs_start_transaction() fails
When btrfs_start_transaction() fails, we should call btrfs_std_error()
properly for filesystem to readonly.
(in this patch, forced readonly framework is used)
Signed-off-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
---
fs/btrfs/file.c | 1 +
fs/btrfs/inode.c | 34 +++++++++++++++++++++++++++-------
fs/btrfs/ioctl.c | 11 ++++++++++-
fs/btrfs/relocation.c | 4 +++-
2013 Feb 07
1
[PATCH] Btrfs: cleanup orphan reservation if truncate fails
I noticed we were getting lots of warnings with xfstest 83 because we have
reservations outstanding. This is because we moved the orphan add outside
of the truncate, but we don''t actually cleanup our reservation if something
fails. This fixes the problem and I no longer see warnings. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
---
fs/btrfs/inode.c | 2 ++
1
2013 Nov 19
6
[PATCH] Btrfs: fix very slow inode eviction and fs unmount
The inode eviction can be very slow, because during eviction we
tell the VFS to truncate all of the inode''s pages. This results
in calls to btrfs_invalidatepage() which in turn does calls to
lock_extent_bits() and clear_extent_bit(). These calls result in
too many merges and splits of extent_state structures, which
consume a lot of time and cpu when the inode has many pages. In
some
2012 Apr 20
44
Ceph on btrfs 3.4rc
After running ceph on XFS for some time, I decided to try btrfs again.
Performance with the current "for-linux-min" branch and big metadata
is much better. The only problem (?) I''m still seeing is a warning
that seems to occur from time to time:
[87703.784552] ------------[ cut here ]------------
[87703.789759] WARNING: at fs/btrfs/inode.c:2103
2011 Jul 26
0
[PATCH] Btrfs: use bytes_may_use for all ENOSPC reservations
We have been using bytes_reserved for metadata reservations, which is wrong
since we use that to keep track of outstanding reservations from the allocator.
This resulted in us doing a lot of silly things to make sure we don''t allocate a
bunch of metadata chunks since we never had a real view of how much space was
actually in use by metadata.
There are a lot of fixes in here to make this
2011 Jul 27
0
[PATCH] Btrfs: use bytes_may_use for all ENOSPC reservations V2
We have been using bytes_reserved for metadata reservations, which is wrong
since we use that to keep track of outstanding reservations from the allocator.
This resulted in us doing a lot of silly things to make sure we don''t allocate a
bunch of metadata chunks since we never had a real view of how much space was
actually in use by metadata.
There are a lot of fixes in here to make this
2012 Jul 31
0
[PATCH V2 1/2] Btrfs: fix error path in create_pending_snapshot()
This patch fixes the following problem:
- If we failed to deal with the delayed dir items, we should abort transaction,
just as its comment said. Fix it.
- If root reference or root back reference insertion failed, we should
abort transaction. Fix it.
- Do not restore the trans->rsv if we doesn''t change it.
- make the error path more clearly.
Signed-off-by: Miao Xie
2011 Nov 01
0
[PATCH] Btrfs: release metadata from global reserve if we have to fallback for unlink
I fixed a problem where we weren''t reserving space for an orphan item when we
had to fallback to using the global reserve for an unlink, but I introduced
another problem. I was migrating the bytes from the transaction reserve to the
global reserve and then releasing from the global reserve in
btrfs_end_transaction(). The problem with this is that a migrate will jack up
the size for the
2011 Nov 09
12
WARNING: at fs/btrfs/inode.c:2198 btrfs_orphan_commit_root+0xa8/0xc0
Hello,
I''m seeing a lot of warnings in dmesg with a BTRFS filesystem. I''m using
the 3.1 kernel, I found a patch for these warnings (
http://marc.info/?l=linux-btrfs&m=131547325515336&w=2)
<http://marc.info/?l=linux-btrfs&m=131547325515336&w=2>, but that patch
has already been included in 3.1. Are there any other patches I can try?
I''m using
2012 Sep 06
2
[PATCH V4 01/12] Btrfs: fix error path in create_pending_snapshot()
This patch fixes the following problem:
- If we failed to deal with the delayed dir items, we should abort transaction,
just as its comment said. Fix it.
- If root reference or root back reference insertion failed, we should
abort transaction. Fix it.
- Fix the double free problem of pending->inherit.
- Do not restore the trans->rsv if we doesn''t change it.
- make the error path
2010 Jun 10
0
[PATCH] [12/23] BTRFS: Clean up unused variables -- bugs
These are all the cases where a variable is set, but not
read which are really bugs.
- Couple of incorrect error handling fixed.
- One incorrect use of a allocation policy
- Some other things
Still needs more review.
Found by gcc 4.6''s new warnings
Cc: chris.mason@oracle.com
cc: linux-btrfs@vger.kernel.org
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
2012 Nov 01
0
[PATCH 1/5] Btrfs: fix joining the same transaction handler more than 2 times
If we flush inodes with pending delalloc in a transaction, we may join
the same transaction handler more than 2 times.
The reason is:
Task use_count of trans handle
commit_transaction 1
|-> btrfs_start_delalloc_inodes 1
|-> run_delalloc_nocow 1
|-> join_transaction 2
|-> cow_file_range 2
|-> join_transaction 3
In fact, cow_file_range needn''t
2009 Aug 24
0
[PATCH] Btrfs: proper metadata -ENOSPC handling
This patch finally gives us full proper -ENOSPC handling for btrfs. Now
whenever you do a btrfs_start_transaction, you must specify the number of items
you are planning to add/delete/modify. The worst case number of blocks that
could be modified by changing that number of items will be calculated and
checked against the amount of free space in the space_info where the root you
are modifying
2010 Nov 19
1
Btrfs_truncate ?
Hi list
This happened when running an iozone test over ceph, it was doing lots of random reads.
I have no idea how to properly interpret this, I should find it out. Let me know if you need something else.
Thanks!
[69003.803272] ------------[ cut here ]------------
[69003.807987] kernel BUG at fs/btrfs/inode.c:6230!
[69003.807987] invalid opcode: 0000 [#1] SMP
[69003.807987] last sysfs file: