Hi Chris,
Those bugs are small, and the fixes are simple and straitforward.
You can pull from:
git://repo.or.cz/linux-btrfs-devel.git for-chris
Li Zefan (2):
Btrfs: Check if btrfs_next_leaf() returns error in btrfs_listxattr()
Btrfs: Check if btrfs_next_leaf() returns
btrfs_next_leaf() can return -errno, and we should propagate
it to userspace.
This also simplifies how we walk the btree path.
Signed-off-by: Li Zefan l...@cn.fujitsu.com
---
fs/btrfs/xattr.c | 33 -
1 files changed, 12 insertions(+), 21 deletions(-)
diff
btrfs_next_leaf() can return -errno, and we should propagate
it to userspace.
This also simplifies how we walk the btree path.
Signed-off-by: Li Zefan l...@cn.fujitsu.com
---
fs/btrfs/inode.c | 28 ++--
1 files changed, 10 insertions(+), 18 deletions(-)
diff --git
From: Miao Xie mi...@cn.fujitsu.com
Link count of the inode is not decreased if btrfs_set_inode_index()
fails.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
Singed-off-by: Li Zefan l...@cn.fujitsu.com
---
fs/btrfs/inode.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff
Now 'btrfs subvolume snapshot' takes not two but only at least two
parameters. Additionally, the help message is updated accordingly.
Signed-off-by: Andreas Philipp philipp.andr...@gmail.com
---
btrfs.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/btrfs.c
Added BTRFS_IOC_SNAP_CREATE_V2 and struct btrfs_ioctl_vol_args_v2 as
defined in fs/btrfs/ioctl.h in the kernel sources.
Signed-off-by: Andreas Philipp philipp.andr...@gmail.com
---
ioctl.h | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/ioctl.h b/ioctl.h
Signed-off-by: Andreas Philipp philipp.andr...@gmail.com
---
ioctl-test.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/ioctl-test.c b/ioctl-test.c
index 7cf3bc2..1c27d61 100644
--- a/ioctl-test.c
+++ b/ioctl-test.c
@@ -22,6 +22,7 @@ unsigned long ioctls[] = {
Use BTRFS_IOC_CREATE_SNAP_V2 instead of BTRFS_IOC_CREATE_SNAP and add
an option for the creation of a readonly snapshot.
Signed-off-by: Andreas Philipp philipp.andr...@gmail.com
---
btrfs_cmds.c | 44
1 files changed, 36 insertions(+), 8
Signed-off-by: Andreas Philipp philipp.andr...@gmail.com
---
man/btrfs.8.in | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/man/btrfs.8.in b/man/btrfs.8.in
index 26ef982..b59bc6f 100644
--- a/man/btrfs.8.in
+++ b/man/btrfs.8.in
@@ -5,7 +5,7 @@
.SH NAME
btrfs
Hi
On Wed, Apr 13, 2011 at 01:03:56AM +0200, Sébastien Bernard wrote:
Then, after writing on the disk, I got a lot of warning:
[ 822.515875] Kernel unaligned access at TPC[103c2204]
I peeked a look at the btrf_csum_final and here's the function :
void btrfs_csum_final(u32 crc, char
Excerpts from Li Zefan's message of 2011-04-13 03:42:01 -0400:
Hi Chris,
Those bugs are small, and the fixes are simple and straitforward.
You can pull from:
git://repo.or.cz/linux-btrfs-devel.git for-chris
Thanks these are now in my master branch.
-chris
--
To unsubscribe from
Excerpts from Sergei Trofimovich's message of 2011-04-12 17:23:33 -0400:
On Mon, 11 Apr 2011 15:50:48 -0400
Josef Bacik jo...@redhat.com wrote:
On 04/11/2011 03:44 PM, Sergei Trofimovich wrote:
Fix data corruption caused by memcpy() usage on overlapping data.
I've observed it first
On Tue, Apr 12, 2011 at 08:42:39AM -0400, Josef Bacik wrote:
hmm, the goto will lead to problems, cause in out clause there is a
mutex_unlock(), which
we do not have a mutex_lock yet.
Hrm I wonder why xfstests didn't trip over that, thats what I get for patching
while watching the
On Tue, Apr 12, 2011 at 07:42:07PM +0100, Hugo Mills wrote:
There will be savings in the future, however -- when I add Li's
suggestion for tracking the number of bytes (in the block groups as a
whole, and in terms of useful data stored), plus the vaddr of the
last-moved block group, the
A very good question indeed! ;-)
Regards
//Ernst Sjöstrand
On Tue, Mar 29, 2011 at 14:13, Thomas Backlund t...@mandriva.org wrote:
Chris Mason skrev 10.2.2011 14:17:
Excerpts from Ben Gamari's message of 2011-02-09 21:52:20 -0500:
Hey all,
Over the last several months there have been many
fs_info has now ~9kb, more than fits into one page. This will cause
mount failure when memory is too fragmented. Top space consumers are
super block structures super_copy and super_for_commit, ~2.8kb each.
Allocate them dynamically. fs_info will be ~3.5kb. (measured on x86_64)
Add a wrapper for
There are a bunch of places where we do btrfs_join_transaction(root, 1), but
really we set the block_rsv to the delalloc reserve because our metadata was
reserved at delalloc time. This means we don't need to reserve space at all,
and can just join the transaction and go. This patch also fixes a
On 13.04.2011 18:06, Josef Bacik wrote:
There are a bunch of places where we do btrfs_join_transaction(root, 1), but
really we set the block_rsv to the delalloc reserve because our metadata was
reserved at delalloc time. This means we don't need to reserve space at all,
and can just join the
On 04/13/2011 12:34 PM, Arne Jansen wrote:
On 13.04.2011 18:06, Josef Bacik wrote:
There are a bunch of places where we do btrfs_join_transaction(root, 1), but
really we set the block_rsv to the delalloc reserve because our metadata was
reserved at delalloc time. This means we don't need to
In the prealloc filling code and compressed code we don't set trans-block_rsv
to the delalloc block reserve properly, which is going to make us use metadata
from the wrong pool, this patch fixes that. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
fs/btrfs/inode.c |2 ++
1 files
I keep forgetting that btrfs_join_transaction() just ignores the num_items
argument, which leads me to sending pointless patches and looking stupid :). So
just kill the num_items argument from btrfs_join_transaction and
btrfs_start_ioctl_transaction, since neither of them use it. Thanks,
From: David Sterba d...@jikos.cz
Date: Wed, 13 Apr 2011 11:40:37 +0200
On Wed, Apr 13, 2011 at 01:03:56AM +0200, Sébastien Bernard wrote:
Then, after writing on the disk, I got a lot of warning:
[ 822.515875] Kernel unaligned access at TPC[103c2204]
I peeked a look at the btrf_csum_final
There have been many sporadic reports of the following panic
[ cut here ]
kernel BUG at fs/btrfs/extent-tree.c:5498!
invalid opcode: [#1] PREEMPT SMP
last sysfs file: /sys/devices/system/cpu/cpu7/cache/index2/shared_cpu_map
CPU 7
Modules linked in: btrfs zlib_deflate
We currently track trans handles in current-journal_info, but we don't actually
use it. This patch fixes it. This will cover the case where we have multiple
people starting transactions down the call chain. This keeps us from having to
allocate a new handle and all of that, we just increase the
On Wed, 13 Apr 2011 07:32:59 -0400
Chris Mason chris.ma...@oracle.com wrote:
This is in the master branch now, please give it another test. Thanks a
lot for bisecting down and patching!
Tested on btrfs-unstable/master. Works correctly. Reverting
3387206f26e1b48703e810175b98611a4fd8e8ea (to
On 13.04.2011 20:54, Josef Bacik wrote:
There have been many sporadic reports of the following panic
[ cut here ]
kernel BUG at fs/btrfs/extent-tree.c:5498!
invalid opcode: [#1] PREEMPT SMP
last sysfs file: /sys/devices/system/cpu/cpu7/cache/index2/shared_cpu_map
On Thu, Apr 14, 2011 at 2:54 AM, Josef Bacik jo...@redhat.com wrote:
There have been many sporadic reports of the following panic
[ cut here ]
kernel BUG at fs/btrfs/extent-tree.c:5498!
invalid opcode: [#1] PREEMPT SMP
last sysfs file:
On 04/13/2011 06:08 PM, Arne Jansen wrote:
On 13.04.2011 20:54, Josef Bacik wrote:
There have been many sporadic reports of the following panic
[ cut here ]
kernel BUG at fs/btrfs/extent-tree.c:5498!
invalid opcode: [#1] PREEMPT SMP
last sysfs file:
On 04/13/2011 08:26 PM, Yan, Zheng wrote:
On Thu, Apr 14, 2011 at 2:54 AM, Josef Bacikjo...@redhat.com wrote:
There have been many sporadic reports of the following panic
[ cut here ]
kernel BUG at fs/btrfs/extent-tree.c:5498!
invalid opcode: [#1] PREEMPT SMP
last
29 matches
Mail list logo
