I hit this BTRFS oops [1] in 3.0-rc3, clearly due to filesystem corruption.
If lookup_extent_backref fails, path-nodes[0] reasonably could be
null, so look before leaping [2].
Chris, if happy, can you squeeze this into the drop for -rc4 please?
Signed-off-by: Daniel J Blueman
Payment number: G-900-94
This is a confidential message from the Microsoft/Yahoo Office, You have been
approved by the Microsoft/Yahoo Foundation Payment Board to receive a cash
grant of $552,000.00 Dollars E-mail us on:
esq.wilson.harli...@live.commailto:esq.wilson.harli...@live.com
contact
(2011/06/19 13:34), Tsutomu Itoh wrote:
Hi, Chris,
(2011/06/18 6:12), Chris Mason wrote:
Hi everyone,
I think I tracked down the oops we were seeing Tsutomu Itoh's balance
test. The delayed metadata insertion code was allowing delayed updates
to queue up and be process after the snapshot
Hi everyone,
The for-linus branch of the btrfs unstable repo:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git for-linus
Has our current queue of fixes. One of the fixes removes our unused
sysfs code, mostly because gcc likes to complain about it since
we removed some
On 06/18/2011 11:21 PM, David Sterba wrote:
Hi,
On Thu, Jun 16, 2011 at 05:41:10PM +0800, Liu Bo wrote:
--- a/fs/btrfs/btrfs_inode.h
+++ b/fs/btrfs/btrfs_inode.h
@@ -29,11 +29,6 @@ struct btrfs_inode {
/* which subvolume this inode belongs to */
struct btrfs_root *root;
-
On fri, 17 Jun 2011 10:10:31 -0600, Jim Schutt wrote:
I've hit this delayed-inode BUG several times. I'm using btrfs
as the data store for Ceph OSDs, and testing a heavy write load.
The kernel I'm running is a recent commit (f8f44f09eaa) from
Linus' tree with the for-chris branch (commit
In btrfs's in-memory inode, there is a btrfs_key which has the structure:
- key.objectid
- key.type
- key.offset
however, we only use key.objectid to search, to check or something else,
and to reduce in-memory inode size I just keep what is valuable.
v1-v2: update a more proper typo for inode
As btrfs uses delay allocation mechanism and data=order mode, there can be
a period window, during which we sub delalloc_bytes and add_inode_bytes,
and we may get a value of '0' referred to inode's blocks via 'ls -lis'.
ino:291 blocks:198656 i_blocks:0 i_bytes:0 delalloc_bytes:101711872
ino:291
Memory areas [ptr, ptr+total_len] and [name, name+total_len]
may overlap, so it's wrong to use memcpy().
Signed-off-by: Li Zefan l...@cn.fujitsu.com
---
fs/btrfs/ioctl.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index
