Hi Dave,
Il 03/03/2011 22:39, Dave Chinner ha scritto:
WTF? Why does append mode have any effect on whether we can punch
holes in a file or not? There's no justification for adding this in
the commit message. Why is it even in a patch that is for checking
immutable inodes? What is the point
Looks good to me. Thanks!
Another mysterious thing is that this problem can only be recreated on x86
32bit system. I can not recreate it on x86_64 system using my test case. Any
one have any idea about it?
-Original Message-
From: Josef Bacik [mailto:jo...@redhat.com]
Sent: Friday,
Excerpts from Chris Mason's message of 2011-03-03 20:51:55 -0500:
Excerpts from Zhong, Xin's message of 2011-03-02 05:58:49 -0500:
It seems that if we give an unaligned address to btrfs write and the buffer
reside on more than 2 pages. It will trigger this bug.
If we give an aligned
It works well for me too.
From: chris.ma...@oracle.com
To: chris.ma...@oracle.com
CC: xin.zh...@intel.com; mitch.har...@sabayonlinux.org;
thierryzh...@hotmail.com; linux-btrfs@vger.kernel.org
Subject: RE: [PATCH] btrfs file write debugging patch
2011/3/4 Xin Zhong thierryzh...@hotmail.com:
It works well for me too.
From: chris.ma...@oracle.com
To: chris.ma...@oracle.com
CC: xin.zh...@intel.com; mitch.har...@sabayonlinux.org;
thierryzh...@hotmail.com; linux-btrfs@vger.kernel.org
Subject:
a) rename() plays with i_nlink of old_inode; bad, since it's not
locked. I'd add a variant of btrfs_unlink_inode() that would leave
btrfs_drop_nlink()/btrfs_update_inode() to callers and use it instead.
b) btrfs_link() doesn't check for i_nlink overflows. I don't
know if there's
old_inode is not locked; it's not safe to play with its link
count. Instead of bumping it and calling btrfs_unlink_inode(),
add a variant of the latter that does not do btrfs_drop_nlink()/
btrfs_update_inode(), call it instead of btrfs_inc_nlink()/
btrfs_unlink_inode() and do btrfs_update_inode()
Signed-off-by: Al Viro v...@zeniv.linux.org.uk
---
fs/btrfs/inode.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 099d64c..8a6df03 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -4826,6 +4826,9 @@ static int
On Fri, Mar 4, 2011 at 9:33 AM, Mitch Harder
mitch.har...@sabayonlinux.org wrote:
2011/3/4 Xin Zhong thierryzh...@hotmail.com:
It works well for me too.
From: chris.ma...@oracle.com
To: chris.ma...@oracle.com
CC: xin.zh...@intel.com;
This fixes a problem where if truncate fails the inode will still be on the in
memory orphan list. This is will make us complain when the inode gets destroyed
because it's still on the orphan list. So if we fail just remove us from the in
memory list and carry on.
Signed-off-by: Josef Bacik
We don't need an orphan item when expanding files, we just need them for
truncating them, so only add the orphan item in btrfs_truncate instead of in
btrfs_setsize. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
fs/btrfs/inode.c | 45 ++---
1
Mark_inode_dirty will call btrfs_dirty_inode which will take care of updating
the inode. This makes setsize a little cleaner since we don't have to start a
transaction and update the inode in there, we can just call mark_inode_dirty.
Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
-truncate() is going away, instead all of the work needs to be done in
-setattr(). So this converts us over to do this. It's fairly straightforward,
just get rid of our .truncate inode operation and call btrfs_truncate() directly
from btrfs_setsize. This works out better for us since truncate
Argh it helps if I send the right damn patch...
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index e4802f1..6e86afe 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -2528,7 +2528,7 @@ void btrfs_orphan_post_snapshot(struct btrfs_trans_handle
*trans,
Everytime I have to deal with btrfs_cont_expand I stare at it for 20 minutes
trying to remember what exactly it does and why the hell we need it. So add a
comment to save future-Josef some time. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
fs/btrfs/inode.c |6 ++
1 files
Hi, everybody
I have BTRFS RAID0 setup with two disks. After some incident where I
had to force shutdown machine this array won't mount anymore, even
after btrfs device scan. Unfortunately, I don't have backups since I
can't afford another 4TB of storage. I've read that fsck tool for
BTRFS that
On Fri, Mar 4, 2011 at 5:59 PM, Alexey A Nikitin moonwal...@syrius.us wrote:
I have BTRFS RAID0 setup with two disks. After some incident where I
had to force shutdown machine this array won't mount anymore, even
after btrfs device scan. Unfortunately, I don't have backups since I
can't afford
So it works well now with the two patches from Chris on your system. Am I right?
Date: Fri, 4 Mar 2011 11:21:36 -0600
Subject: Re: [PATCH] btrfs file write debugging patch
From: mitch.har...@sabayonlinux.org
To: thierryzh...@hotmail.com
CC:
I pulled the btrfs-select-super source from get branch 'next',
compiled it, but when I run it using
./btrfs-select-super -s 1 /dev/sdb1
all I get is
btrfs-select-super: disk-io.c:739: open_ctree_fd: Assertion
`!(!tree_root-node)' failed
Any ideas what might be wrong and how I can remedy it?
Hi Miao,
With the V3 patch applied, I was able to run dbench 50 without a problem.
Thanks,
On Thu, 03 Mar 2011 14:15:44 +0800
Miao Xie mi...@cn.fujitsu.com wrote:
On Thu, 24 Feb 2011 23:02:55 +0900, Itaru Kitayama wrote:
I have applied the V2 patch on top of the next-rc branch of
On Fri, Mar 4, 2011 at 7:20 PM, Alexey A Nikitin moonwal...@syrius.us wrote:
I pulled the btrfs-select-super source from get branch 'next',
compiled it, but when I run it using
./btrfs-select-super -s 1 /dev/sdb1
all I get is
btrfs-select-super: disk-io.c:739: open_ctree_fd: Assertion
2011/3/4 cwillu cwi...@cwillu.com:
On Fri, Mar 4, 2011 at 7:20 PM, Alexey A Nikitin moonwal...@syrius.us wrote:
all I get is
btrfs-select-super: disk-io.c:739: open_ctree_fd: Assertion
`!(!tree_root-node)' failed
Make sure you run it as root, and try both -s 1 and -s 2.
Done that -
On Thu, Feb 17, 2011 at 7:09 PM, Chris Mason
This work is really cool, thanks for doing it. I'm starting a run on
this tonight and if all goes well I'll review in detail and try to queue
it along with the per-subvolume storage bits for .39.
Thanks!
-chris
This is the kind of thing --
Hi Miao,
The V3 patch on top of the next-rc fails to pass an xfstests test 13.
In the btrfs link path, we need to reserve one more metadata in the
trans_block_rsv for the delayed inode update (if needed) to complete.
Here's the log from the test:
[ cut here ]
kernel BUG
24 matches
Mail list logo
