sctx is removed from the argument of the function that
doesn't use sctx.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/send.c | 189 +++-
1 file changed, 90 insertions(+), 99 deletions(-)
diff --git a/fs/btrfs/send.c b/fs
patchset.
Your patchset looks good to me. Thanks.
Tested-by: Tsutomu Itoh t-i...@jp.fujitsu.com
But no space error is not a serious problem when we write out the inode cache,
and it is safe that we just skip this step if we meet this problem. So we need
not abort the current transaction
Hi,
I encountered following BUG_ON. (I think that -28(ENOSPC) returned from
btrfs_orphan_reserve_metadata maybe.)
When this happened, I was running my stress test. But, I cannot reproduce
this problem yet though the test was executed again several times.
- Tsutomu
[ 4823.473913] btrfs: found
(2010/12/08 19:01), liubo wrote:
While compiling btrfs, I got belows:
CC [M] fs/btrfs/inode.o
fs/btrfs/inode.c: In function ‘btrfs_end_dio_bio’:
fs/btrfs/inode.c:5720: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 4 has type ‘sector_t’
LD [M] fs/btrfs/btrfs.o
(2010/12/16 17:44), Tsutomu Itoh wrote:
Hi,
In btrfs, inode number is increased each time a new file or directory
is made.
Therefore, if the making deletion of the file is repeated, value of
'i_ino' increases rapidly.
For example, inode number changes as follows.
$ touch foo
In btrfs_read_fs_root_no_radix(), 'root' is not freed if
btrfs_search_slot() returns error.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
disk-io.c |1 +
1 file changed, 1 insertion(+)
diff -urNp linux-2.6.37-rc7/fs/btrfs/disk-io.c
linux-2.6.37-rc7.new/fs/btrfs/disk-io.c
--- linux
Should check if functions returns NULL or not.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/ctree.c |6 ++
fs/btrfs/disk-io.c |8
fs/btrfs/extent_io.c |2 ++
3 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/ctree.c b/fs
(2011/01/21 1:09), Josef Bacik wrote:
I'd rather we go through and have these things return an error than do a
BUG_ON(). We're moving towards a more stable BTRFS, not one that panics more
often :).
Yes, I also think so.
This patch is my first step.
My modification policy is as follows:
1.
(2011/01/21 8:47), Tsutomu Itoh wrote:
(2011/01/21 1:09), Josef Bacik wrote:
I'd rather we go through and have these things return an error than do a
BUG_ON(). We're moving towards a more stable BTRFS, not one that panics more
often :).
Yes, I also think so.
This patch is my first step
btrfs_start_ioctl_transaction() returns ERR_PTR(), not NULL.
So, it is necessary to use IS_ERR() to check the return value.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/ioctl.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -urNp linux-2.6.38-rc1/fs/btrfs
returned.
As a long-term plan:
- BUG_ON() is reduced by using the forced-readonly framework, etc.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/disk-io.c |5 +
fs/btrfs/extent-tree.c |2 +-
fs/btrfs/inode.c | 24
fs/btrfs/ioctl.c
When btrfs_alloc_path() fails, btrfs_free_path() need not be called.
Therefore, it changes the branch ahead.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/inode.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -urNp linux-2.6.38-rc3/fs/btrfs/inode.c
linux-2.6.38
)
- The error code is returned in the place where the error can be
easily returned.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
V1-V2:
- In btrfs_init_new_device(), if btrfs_start_transaction() failed,
it is necessary to free device-name.
fs/btrfs/extent-tree.c |7 +--
fs/btrfs
(2011/02/12 20:17), Yoshinori Sano wrote:
To make Btrfs code more robust, several return value checks where memory
allocation can fail are introduced. I use BUG_ON where I don't know how
to handle the error properly, which increases the number of using the
notorious BUG_ON, though.
I add the check on the return value of alloc_extent_map() to several places.
In addition, alloc_extent_map() returns only the address or NULL.
Therefore, check by IS_ERR() is unnecessary. So, I remove IS_ERR() checking.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/extent-tree.c
Sano-san,
(2011/02/14 22:57), Yoshinori Sano wrote:
2011年2月14日8:57 Tsutomu Itoh t-i...@jp.fujitsu.com:
(2011/02/12 20:17), Yoshinori Sano wrote:
To make Btrfs code more robust, several return value checks where memory
allocation can fail are introduced. I use BUG_ON where I don't know how
Adding the check on the return value of btrfs_alloc_path() to several places.
And, some of callers are modified by this change.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/compression.c | 11 +++
fs/btrfs/dir-item.c| 13 +
fs/btrfs/file-item.c
(2011/03/05 16:01), Itaru Kitayama wrote:
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.
Miao's patch
This patch changes some BUG_ON() to the error return.
(but, most callers still use BUG_ON())
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/ctree.c |3 ++-
fs/btrfs/disk-io.c |5 -
fs/btrfs/extent-tree.c | 25 ++---
fs/btrfs/file-item.c
This patch is checking return value of read_tree_block(),
and if it is NULL, error processing.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/ctree.c |3 +++
fs/btrfs/extent-tree.c |6 ++
fs/btrfs/relocation.c |6 ++
3 files changed, 15 insertions
-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/file.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -urNp linux-2.6.39-rc1/fs/btrfs/file.c linux-2.6.39-rc1.new/fs/btrfs/file.c
--- linux-2.6.39-rc1/fs/btrfs/file.c2011-03-30 04:09:47.0 +0900
+++ linux-2.6.39-rc1.new/fs
,relatime,compress 0 0
[after]
$ mount | grep sdc2
/dev/sdc2 on /test12 type btrfs (rw,space_cache,compress=lzo)
$ cat /proc/mounts | grep sdc2
/dev/sdc2 /test12 btrfs rw,relatime,compress=lzo,space_cache 0 0
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/super.c
Free btrfs_trans_handle if btrfs_commit_transaction_async() fails.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/ioctl.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -urNp linux-2.6.39-rc1/fs/btrfs/ioctl.c
linux-2.6.39-rc1.new/fs/btrfs/ioctl.c
--- linux
Sorry. Ignore previous patch.
New patch is as follows.
Thanks,
Tsutomu
(2011/04/04 10:09), Tsutomu Itoh wrote:
Free btrfs_trans_handle if btrfs_commit_transaction_async() fails.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/ioctl.c |4 +++-
1 file changed, 3
(2011/04/09 11:23), Yoshinori Sano wrote:
This patch checks return value of btrfs_alloc_path() and removes BUG_ON().
Signed-off-by: Yoshinori Sano yoshinori.s...@gmail.com
---
fs/btrfs/dir-item.c|2 ++
fs/btrfs/extent-tree.c | 12
fs/btrfs/file-item.c |6
(2011/04/12 7:46), Yoshinori Sano wrote:
Thank you for your review.
I modified the previous patch.
Other points still existed. I'm sorry not to point it out at a time.
Specifically, all the callers that calls the following are modified
because of the lack of return value check:
-
The error processing of several places is changed like setting the
error number only at the error.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/inode.c | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
The check on the return value of kmalloc() in inode.c is added.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
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 a4157cf..c718d27 100644
--- a/fs/btrfs
'trans' and 'root' argument not used in fixup_low_keys() are deleted.
And, the argument that became unnecessary is deleted about the caller
of fixup_low_keys().
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/ctree.c | 49 ---
fs
(2011/04/21 19:59), David Sterba wrote:
Hi,
On Thu, Apr 21, 2011 at 06:54:45PM +0900, Tsutomu Itoh wrote:
'trans' and 'root' argument not used in fixup_low_keys() are deleted.
And, the argument that became unnecessary is deleted about the caller
of fixup_low_keys().
heh, coincidence
The check on the return value of kmalloc() is added to some places.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
V1-V2: adding check code to relocate_one_extent() for the readability,
which is suggested by David Sterba.
fs/btrfs/extent-tree.c |4
fs/btrfs/inode.c
It is necessary to unlock mutex_lock before it return an error when
btrfs_alloc_path() fails.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/tree-log.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index
(2011/04/22 21:45), David Sterba wrote:
Hi,
On Fri, Apr 22, 2011 at 06:05:40PM +0900, Tsutomu Itoh wrote:
It is necessary to unlock mutex_lock before it return an error when
btrfs_alloc_path() fails.
good catch! however I suggest to move the mutex_lock after the
allocation and check
(2011/04/22 18:41), David Sterba wrote:
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/extent-tree.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 31f33ba..c97ceab 100644
---
When read_one_inode() fails, error code is returned to caller instead
of BUG_ON().
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/tree-log.c | 24 ++--
1 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
If return value of btrfs_inc_extent_ref() is not 0, BUG() is called.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/tree-log.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index f997ec0..23fb42d 100644
--- a/fs
The error code is returned instead of calling BUG_ON when
btrfs_del_item returns the error.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/file-item.c | 10 ++
fs/btrfs/root-tree.c |6 +-
fs/btrfs/tree-log.c | 10 +++---
fs/btrfs/volumes.c |4
Currently, btrfs_truncate_item and btrfs_extend_item returns only 0.
So, the check by BUG_ON in the caller is unnecessary.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/ctree.c |8 ++--
fs/btrfs/dir-item.c|1 -
fs/btrfs/extent-tree.c |3 ---
fs/btrfs
The error code is returned instead of calling BUG_ON when
btrfs_previous_item returns the error.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/volumes.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index
The panic occurred when 'btrfs fi bal /test5' was executed.
/test5 is as follows:
# mount -o space_cache,compress=lzo /dev/sdc3 /test5
#
# btrfs fi sh /dev/sdc3
Label: none uuid: 38ec48b2-a64b-4225-8cc6-5eb08024dc64
Total devices 5 FS bytes used 7.87MB
devid1 size 10.00GB
(2011/05/31 10:13), Chris Mason wrote:
Excerpts from Tsutomu Itoh's message of 2011-05-30 20:27:51 -0400:
The panic occurred when 'btrfs fi bal /test5' was executed.
/test5 is as follows:
# mount -o space_cache,compress=lzo /dev/sdc3 /test5
#
# btrfs fi sh /dev/sdc3
Label: none uuid:
(2011/05/31 15:13), liubo wrote:
On 05/31/2011 12:31 PM, Tsutomu Itoh wrote:
(2011/05/31 10:13), Chris Mason wrote:
Excerpts from Tsutomu Itoh's message of 2011-05-30 20:27:51 -0400:
The panic occurred when 'btrfs fi bal /test5' was executed.
/test5 is as follows:
# mount -o space_cache
Hi,
(2011/05/31 19:16), Arne Jansen wrote:
The following functions had a struct btrfs_root * parameter which went
unused:
btrfs_set_block_group_rw
btrfs_destroy_delayed_refs
btrfs_csum_data
extent_data_ref_count
copy_to_sk
Signed-off-by: Arne Jansen sensi...@gmx.net
---
Hi, liubo,
(2011/06/01 18:42), liubo wrote:
On 06/01/2011 04:12 PM, liubo wrote:
On 06/01/2011 03:44 PM, liubo wrote:
On 05/31/2011 08:27 AM, Tsutomu Itoh wrote:
The panic occurred when 'btrfs fi bal /test5' was executed.
/test5 is as follows:
# mount -o space_cache,compress=lzo /dev/sdc3
Hi liubo,
(2011/06/01 19:44), Tsutomu Itoh wrote:
Hi, liubo,
(2011/06/01 18:42), liubo wrote:
On 06/01/2011 04:12 PM, liubo wrote:
On 06/01/2011 03:44 PM, liubo wrote:
On 05/31/2011 08:27 AM, Tsutomu Itoh wrote:
The panic occurred when 'btrfs fi bal /test5' was executed.
/test5
Hi,
I encountered following panic using 'btrfs-unstable + for-linus'
kernel.
I ran btrfs fi bal /test5 command, and mount option of /test5
is as follows:
/dev/sdc3 on /test5 type btrfs (rw,space_cache,compress=lzo,inode_cache)
Thanks,
Tsutomu
Hi liubo,
(2011/06/07 14:31), liubo wrote:
On 06/06/2011 04:33 PM, Tsutomu Itoh wrote:
Hi,
I encountered following panic using 'btrfs-unstable + for-linus'
kernel.
I ran btrfs fi bal /test5 command, and mount option of /test5
is as follows:
/dev/sdc3 on /test5 type btrfs (rw
(2011/06/07 14:59), Tsutomu Itoh wrote:
Hi liubo,
(2011/06/07 14:31), liubo wrote:
On 06/06/2011 04:33 PM, Tsutomu Itoh wrote:
Hi,
I encountered following panic using 'btrfs-unstable + for-linus'
kernel.
I ran btrfs fi bal /test5 command, and mount option of /test5
is as follows
(2011/06/07 15:17), Tsutomu Itoh wrote:
(2011/06/07 14:59), Tsutomu Itoh wrote:
Hi liubo,
(2011/06/07 14:31), liubo wrote:
On 06/06/2011 04:33 PM, Tsutomu Itoh wrote:
Hi,
I encountered following panic using 'btrfs-unstable + for-linus'
kernel.
I ran btrfs fi bal /test5 command
(2011/06/08 0:46), Chris Mason wrote:
Excerpts from liubo's message of 2011-06-07 04:36:56 -0400:
On 06/07/2011 04:24 PM, Tsutomu Itoh wrote:
(2011/06/07 15:17), Tsutomu Itoh wrote:
(2011/06/07 14:59), Tsutomu Itoh wrote:
Hi liubo,
(2011/06/07 14:31), liubo wrote:
On 06/06/2011 04:33 PM
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-i...@jp.fujitsu.com
---
fs/btrfs/file.c|1 +
fs/btrfs/inode.c | 34
(2011/06/10 0:51), David Sterba wrote:
On Thu, Jun 09, 2011 at 06:38:52PM +0900, Tsutomu Itoh wrote:
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-i
When btrfs_join_transaction()/btrfs_join_transaction_nolock() fails,
we should call btrfs_std_error() properly for filesystem to readonly.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
This patch is dependent on
http://marc.info/?l=linux-btrfsm=130761239706076w=2
(it is necessary
When btrfs_start_ioctl_transaction() fails, we should call
btrfs_std_error() properly for filesystem to readonly.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
This patch needs btrfs_abort_transaction function.
fs/btrfs/ioctl.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions
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 was created.
I've fixed this up by moving
(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
(2011/06/21 9:40), Chris Mason wrote:
Excerpts from David Sterba's message of 2011-06-20 20:24:35 -0400:
On Mon, Jun 20, 2011 at 08:41:39AM +0900, Tsutomu Itoh wrote:
(2011/06/19 13:34), Tsutomu Itoh wrote:
I've fixed this up by moving the delayed metadata run down into the
snapshot creation
The following functions always return 0.
- add_delayed_ref_head()
- add_delayed_tree_ref()
- add_delayed_data_ref()
- add_excluded_extent()
Therefore, check by BUG_ON() is unnecessary at the caller of these
functions.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs
Hi Alex,
On 2014/03/28 0:50, Alex Lyakas wrote:
Hi Tsutomu Itoh,
On Thu, Mar 21, 2013 at 6:32 AM, Tsutomu Itoh t-i...@jp.fujitsu.com wrote:
We should free leaf and root before returning from the error
handling code.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/disk-io.c
In btrfs_create_tree(), if btrfs_insert_root() fails, we should
free root-commit_root.
Reported-by: Alex Lyakas a...@zadarastorage.com
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/disk-io.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk
I encountered soft lockup when executing 'xfstests btrfs/042' on 3.16-rc1.
[ 1121.983975] BTRFS: device fsid 8cc641f9-563a-4d62-9157-9503156ce62c devid 1
transid 4 /dev/sdc5
[ 1121.987994] BTRFS info (device sdc5): disk space caching is enabled
[ 1121.987999] BTRFS: flagging fs
Hi Chris,
On 2014/06/17 2:56, Chris Mason wrote:
On 06/16/2014 02:35 AM, Tsutomu Itoh wrote:
I encountered soft lockup when executing 'xfstests btrfs/042' on 3.16-rc1.
Did we recover, or was it stuck forever?
The following messages are repeatedly output.
And stuck forever.
[ 1147.942181
On 2014/06/17 8:52, Chris Mason wrote:
On 06/16/2014 07:28 PM, Tsutomu Itoh wrote:
Hi Chris,
On 2014/06/17 2:56, Chris Mason wrote:
On 06/16/2014 02:35 AM, Tsutomu Itoh wrote:
I encountered soft lockup when executing 'xfstests btrfs/042' on 3.16-rc1.
Did we recover, or was it stuck
The return value of btrfs_lookup_dentry is checked so that
the panic such as illegal address reference should not occur.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/inode.c |1 +
fs/btrfs/ioctl.c | 10 +-
2 files changed, 10 insertions(+), 1 deletions(-)
diff
The return value of btrfs_lookup_dentry is checked so that
the panic such as illegal address reference should not occur.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
V1 - V2: unnecessary BUG_ON was deleted
fs/btrfs/ioctl.c | 10 +-
1 files changed, 9 insertions(+), 1
(2011/06/28 23:22), Josef Bacik wrote:
On 06/27/2011 11:34 PM, Tsutomu Itoh wrote:
The return value of btrfs_lookup_dentry is checked so that
the panic such as illegal address reference should not occur.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
Nack, please fix btrfs_lookup_dentry
The return value of btrfs_lookup_dentry is checked so that
the panic such as illegal address reference should not occur.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
V1-V2: unnecessary BUG_ON was deleted
V2-V3: to return -ENOENT instead of NULL when no entry was found,
return
Hi, Miao,
(2011/06/30 15:32), Miao Xie wrote:
Hi, Itoh-san
Could you test the following patch to check whether it can fix the bug or not?
I have tested it on my x86_64 machine by your test script for two days, it
worked well.
I ran my test script about a day, I was not able to reproduce
The return value check of btrfs_alloc_path() in several places is
changed from BUG_ON() to error return.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/extent-tree.c |3 ++-
fs/btrfs/extent_io.c |9 ++---
fs/btrfs/inode.c | 15 +++
fs/btrfs
Hi, Chris,
(2011/07/08 5:26), Chris Mason wrote:
Excerpts from Tsutomu Itoh's message of 2011-07-01 04:11:28 -0400:
Hi, Miao,
(2011/06/30 15:32), Miao Xie wrote:
Hi, Itoh-san
Could you test the following patch to check whether it can fix the bug or
not?
I have tested it on my x86_64
Hi, Chris,
(2011/07/08 5:26), Chris Mason wrote:
Excerpts from Tsutomu Itoh's message of 2011-07-01 04:11:28 -0400:
Hi, Miao,
(2011/06/30 15:32), Miao Xie wrote:
Hi, Itoh-san
Could you test the following patch to check whether it can fix the bug or
not?
I have tested it on my x86_64
(2011/07/15 7:14), Mark Fasheh wrote:
This patch fixes many callers of btrfs_alloc_path() which BUG_ON allocation
failure. All the sites that are fixed in this patch were checked by me to
be fairly trivial to fix because of at least one of two criteria:
- Callers of the function catch
(2011/07/15 7:15), Mark Fasheh wrote:
I also removed the BUG_ON from error return of find_next_chunk in
init_first_rw_device(). It turns out that the only caller of
init_first_rw_device() also BUGS on any nonzero return so no actual behavior
change has occurred here.
Signed-off-by: Mark
(2011/07/15 7:15), Mark Fasheh wrote:
In addition to properly handling allocation failure from btrfs_alloc_path, I
also fixed up the kzalloc error handling code immediately below it.
Need not you correct the caller of btrfs_drop_snapshot()?
Thanks,
Tsutomu
Signed-off-by: Mark Fasheh
Hi, Mark,
(2011/07/15 7:14), Mark Fasheh wrote:
Hi,
The following patches attempt to replace all the paths where we
BUG_ON the return value of btrfs_alloc_path with proper error handling. It's
pretty clear that these places aren't BUGing because of code error. To be
explicit, much of
Hi, Mark,
(2011/07/19 7:09), Mark Fasheh wrote:
On Fri, Jul 15, 2011 at 12:04:46PM +0900, Tsutomu Itoh wrote:
(2011/07/15 7:15), Mark Fasheh wrote:
In addition to properly handling allocation failure from btrfs_alloc_path, I
also fixed up the kzalloc error handling code immediately below
When btrfs_unlink_inode() and btrfs_orphan_add() in btrfs_unlink()
are error, the error code is returned to the caller instead of
BUG_ON().
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/extent-tree.c |3 ++-
fs/btrfs/inode.c | 10 +++---
2 files changed, 9
(2011/07/20 16:58), Chris Mason wrote:
Excerpts from Tsutomu Itoh's message of 2011-07-19 22:08:38 -0400:
(2011/07/20 2:30), Chris Mason wrote:
Hi everyone,
I've pushed out a new integration-test branch, and it includes a new
reader/writer locking scheme for the btree locks.
We've seen a
(2011/07/21 2:21), Chris Mason wrote:
Excerpts from Chris Mason's message of 2011-07-19 13:30:22 -0400:
Hi everyone,
I've pushed out a new integration-test branch, and it includes a new
reader/writer locking scheme for the btree locks.
We've seen a number of benchmarks dominated by
Hi, Mark,
(2011/07/22 4:48), Mark Fasheh wrote:
In addition to properly handling allocation failure from btrfs_alloc_path, I
also fixed up the kzalloc error handling code immediately below it.
Signed-off-by: Mark Fasheh mfas...@suse.com
---
fs/btrfs/extent-tree.c |8 ++--
1 files
needed an update since it calls btrfs_alloc_chunk()
which can now return -ENOMEM. Instead of setting space_info-full on any
error from btrfs_alloc_chunk() I catch and return every error value _except_
-ENOSPC. Thanks goes to Tsutomu Itoh for pointing that issue out.
Signed-off-by: Mark Fasheh
Hi, Chris,
In current for-linus kernel,
When I ran my test script such as a lot of file creation deletion and balance,
the following warning messages were displayed only once.
However, I cannot have it still reproduce...
-Tsutomu
Jul 28 12:01:00 luna kernel: [ 5985.487143] btrfs: found
Hi, Miao,
(2011/07/28 18:08), Miao Xie wrote:
On thu, 28 Jul 2011 17:30:27 +0900, Tsutomu Itoh wrote:
Hi, Chris,
In current for-linus kernel,
When I ran my test script such as a lot of file creation deletion and
balance,
the following warning messages were displayed only once.
However
I ran subvol balance test script at current for-linus branch, I got
following warning messages.
Thanks,
Tsutomu
Aug 3 17:54:01 luna kernel: [21310.079308] [ cut here ]
Aug 3 17:54:01 luna kernel: [21310.079326] WARNING: at
fs/btrfs/extent-tree.c:5703
Hi, Mark,
(2011/08/06 1:48), Mark Fasheh wrote:
Right now in create_snapshot(), we'll BUG() if btrfs_lookup_dentry() returns
a NULL inode (negative dentry). Getting a negative dentry here probably
isn't ever expected to happen however two things lead me to believe that we
should trap this
The filesystem turns readonly instead of returning the error to the
caller when detected error in btrfs_drop_snapshot().
and, because the caller doesn't check the error, the function type is
changed to 'void'.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/ctree.h |4
(2011/08/22 23:22), Wanlong Gao wrote:
From: Wanlong Gao gaowanl...@cn.fujitsu.com
Make btrfs_init_compress() return void, since it always return 0,
and no need to check return value.
Signed-off-by: Wanlong Gao gaowanl...@cn.fujitsu.com
---
fs/btrfs/compression.c |3 +--
If kmalloc() or btrfs_copy_root() in create_reloc_root() failed,
error is returned to the caller instead of BUG_ON().
and, error handling of btrfs_copy_root() is corrected properly.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/ctree.c |5 -
fs/btrfs/relocation.c
The type of some functions that return only 0 is changed to 'void'.
In addition, the check on the return value in the caller of these
functions becomes unnecessary. So, these check is removed.
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
fs/btrfs/async-thread.c | 17
fs
In current for-linus branch, I encountered the problem that the
umount command doesn't end forever.
=
# mount
...
/dev/sdc9 on /test9 type btrfs (rw,space_cache,compress=lzo,autodefrag)
# umount /test9
crash ps | grep umount
13107 6558 0 8801257296c0
The same patch has been posted about one month ago.
http://marc.info/?l=linux-btrfsm=131363399500506w=2
Thanks,
Tsutomu
(2011/09/12 5:33), Grazvydas Ignotas wrote:
Currently getdents syscall returns wrong offset for '.' directory entry,
which confuses some programs like wine. This can be
Hi, David,
(2011/09/30 7:05), David Sterba wrote:
Hi,
xfstests/013 triggered this bug (I've never seen it before, though the
integration-test is basically the same what I was hammering with xfstests
recently):
The problem might be solved by the following patch.
(2011/10/14 2:11), Josef Bacik wrote:
Recently I changed the xattr stuff to unconditionally set the xattr first in
case the xattr didn't exist yet. This has introduced a regression when
setting
an xattr that already exists with a large value. If we find the key we are
looking for
type 'unsigned int', but
argument 3 has type 'long unsigned int'
Signed-off-by: Tsutomu Itoh t-i...@jp.fujitsu.com
---
extent-tree.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/extent-tree.c b/extent-tree.c
index 5bed3c2..5144d57 100644
--- a/extent-tree.c
+++ b/extent
In integration-scrub branch, following warning messages were displayed by
running xfstests.
# btrfs fi sh /dev/sdd4
Label: none uuid: 8f28d85c-e37c-4c1b-adef-2627ca59be78
Total devices 2 FS bytes used 31.49MB
devid1 size 9.31GB used 9.31GB path /dev/sdd4
devid2
(2011/11/03 20:19), Chris Mason wrote:
On Thu, Nov 03, 2011 at 10:25:23AM +0900, Tsutomu Itoh wrote:
In integration-scrub branch, following warning messages were displayed by
running xfstests.
# btrfs fi sh /dev/sdd4
Label: none uuid: 8f28d85c-e37c-4c1b-adef-2627ca59be78
Total
In for-linus branch, when xfstests was executed, the following warning
messages were output.
Thanks,
Tsutomu
===
Nov 7 13:51:00 luna kernel: [ 824.063444] device fsid
2f0ad8a9-93d5-4c99-837f-9db99543133b devid 1 transid
Hi, Chris,
(2011/11/04 8:43), Tsutomu Itoh wrote:
(2011/11/03 20:19), Chris Mason wrote:
On Thu, Nov 03, 2011 at 10:25:23AM +0900, Tsutomu Itoh wrote:
In integration-scrub branch, following warning messages were displayed by
running xfstests.
# btrfs fi sh /dev/sdd4
Label: none uuid
(2011/11/08 1:12), Chris Mason wrote:
On Mon, Nov 07, 2011 at 02:10:29PM +0900, Tsutomu Itoh wrote:
In for-linus branch, when xfstests was executed, the following warning
messages were output.
Dave Sterba and I were consistently getting these last week, but after
fixes from Josef and I
(2011/11/07 21:50), David Sterba wrote:
Hi,
I saw this BUG in current linus' (with last pull included) to quickly
trigger in xfstests/013, with freshly created fs and default raid flags.
I encountered the same panic this morning, too.
My mount option is,
mount option: compress=lzo
1 - 100 of 267 matches
Mail list logo
