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
---
fs/btrfs/ctree.h |4 ++--
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
(2011/08/08 14:55), Randy Barlow wrote:
I started playing with btrfs last night, and I must say that I am very
excited! I do have one question so far. Since I was learning, I created
a sparse file, and then used mkfs to get a btrfs filesystem. I
entertained myself with that for a while, and then
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 btrfs_alloc_free
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 f
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 2799
gt; do_chunk_alloc() also 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
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
> ---
> fs/btrfs/extent-tree.c |8 ++--
> 1 files changed,
(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
(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.
>>
(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 number of benchmarks dominated by contention on the root
> node lock. This changes our locks into a s
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
---
fs/btrfs/extent-tree.c |3 ++-
fs/btrfs/inode.c | 10 +++---
2 files changed, 9 insertions(+), 4 deletions
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 erro
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, mu
(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
>
(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: Mar
(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 e
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 teste
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 teste
The return value check of btrfs_alloc_path() in several places is
changed from BUG_ON() to error return.
Signed-off-by: Tsutomu Itoh
---
fs/btrfs/extent-tree.c |3 ++-
fs/btrfs/extent_io.c |9 ++---
fs/btrfs/inode.c | 15 +++
fs/btrfs/ioctl.c |1 +
4
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 reprodu
(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?
Sure.
After running my test script by about a day, I will report on the result.
Thanks,
Tsutomu
> I have tested it on my x86_64 machine by your test script for t
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
---
V1->V2: unnecessary BUG_ON was deleted
V2->V3: to return -ENOENT instead of NULL when no entry was found,
return va
(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
>
> Nack, please
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
---
V1 -> V2: unnecessary BUG_ON was deleted
fs/btrfs/ioctl.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --gi
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
---
fs/btrfs/inode.c |1 +
fs/btrfs/ioctl.c | 10 +-
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs
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
---
fs/btrfs/delayed-ref.c | 32
(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 mo
(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 updat
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 th
When btrfs_start_ioctl_transaction() fails, we should call
btrfs_std_error() properly for filesystem to readonly.
Signed-off-by: Tsutomu Itoh
---
This patch needs btrfs_abort_transaction function.
fs/btrfs/ioctl.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/fs
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
---
This patch is dependent on
http://marc.info/?l=linux-btrfs&m=130761239706076&w=2
(it is necessary t
(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
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
---
fs/btrfs/file.c|1 +
fs/btrfs/inode.c | 34 +++---
fs
(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
(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 pan
(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.
>
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
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/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:
>>>>>
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.
&
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
> ---
> fs/btrfs/compres
(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'
(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: no
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 used
The error code is returned instead of calling BUG_ON when
btrfs_previous_item returns the error.
Signed-off-by: Tsutomu Itoh
---
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 8b9fb8c..c95b214 100644
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
---
fs/btrfs/ctree.c |8 ++--
fs/btrfs/dir-item.c|1 -
fs/btrfs/extent-tree.c |3 ---
fs/btrfs/file-item.c |3
The error code is returned instead of calling BUG_ON when
btrfs_del_item returns the error.
Signed-off-by: Tsutomu Itoh
---
fs/btrfs/file-item.c | 10 ++
fs/btrfs/root-tree.c |6 +-
fs/btrfs/tree-log.c | 10 +++---
fs/btrfs/volumes.c |4 +---
4 files changed, 19
If return value of btrfs_inc_extent_ref() is not 0, BUG() is called.
Signed-off-by: Tsutomu Itoh
---
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/btrfs/tree-log.c
When read_one_inode() fails, error code is returned to caller instead
of BUG_ON().
Signed-off-by: Tsutomu Itoh
---
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
index f997ec0
(2011/04/22 18:41), David Sterba wrote:
> Signed-off-by: David Sterba
> ---
> 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
> --- a/fs/btrfs/extent-tree.c
>
(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
It is necessary to unlock mutex_lock before it return an error when
btrfs_alloc_path() fails.
Signed-off-by: Tsutomu Itoh
---
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 c50271a..f997ec0
The check on the return value of kmalloc() is added to some places.
Signed-off-by: Tsutomu Itoh
---
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 |3 +++
2 fi
(2011/04/21 21:18), David Sterba wrote:
> On Wed, Apr 20, 2011 at 09:51:30AM +0900, Tsutomu Itoh wrote:
>>> 2030delayed = kmalloc(sizeof(*delayed), GFP_NOFS | __GFP_NOFAIL);
>>
>> I think that it doesn't fail ordinary when __GFP_NOFAIL is specified...
(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 th
'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
---
fs/btrfs/ctree.c | 49 -
eck 'new_extents'.
Thanks,
Tsutomu
>
> IMO the check can be safely added here and get_new_locations cleaned up
> later.
>
> Feel free to fold the changes into your patch.
>
> I did not find any more unchecked allocatinos.
>
>
> dave
>
>
>
The check on the return value of kmalloc() in inode.c is added.
Signed-off-by: Tsutomu Itoh
---
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/inode.c
+++ b/fs/btrfs
The error processing of several places is changed like setting the
error number only at the error.
Signed-off-by: Tsutomu Itoh
---
fs/btrfs/inode.c | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index a4157cf..e8e3a18
(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:
> - btr
(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
> ---
> fs/btrfs/dir-item.c|2 ++
> fs/btrfs/extent-tree.c | 12
> fs/btrfs/file-item.c |6 --
> fs/btrfs/file
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
> ---
> fs/btrfs/ioctl.c |4 +++-
> 1 file changed,
Free btrfs_trans_handle if btrfs_commit_transaction_async() fails.
Signed-off-by: Tsutomu Itoh
---
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-2.6.39-rc1/fs/btrfs
(2011/04/03 21:31), Yoshinori Sano wrote:
> Free btrfs_trans_handle when join_transaction() fails
> in start_transaction()
Woops! It's my mistake in http://marc.info/?l=linux-btrfs&m=130086817629289&w=2.
Thanks for the point.
---
Tsutomu
>
> Signed-off-by: Yoshinori Sano
> ---
> fs/btrfs/tran
,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
---
fs/btrfs/super.c | 19
ning.
Signed-off-by: Tsutomu Itoh
---
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/btrf
This patch is checking return value of read_tree_block(),
and if it is NULL, error processing.
Signed-off-by: Tsutomu Itoh
---
fs/btrfs/ctree.c |3 +++
fs/btrfs/extent-tree.c |6 ++
fs/btrfs/relocation.c |6 ++
3 files changed, 15 insertions(+)
diff -urNp linux
This patch changes some BUG_ON() to the error return.
(but, most callers still use BUG_ON())
Signed-off-by: Tsutomu Itoh
---
fs/btrfs/ctree.c |3 ++-
fs/btrfs/disk-io.c |5 -
fs/btrfs/extent-tree.c | 25 ++---
fs/btrfs/file-item.c |3 ++-
fs
(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 (http://marc.in
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
---
fs/btrfs/compression.c | 11 +++
fs/btrfs/dir-item.c| 13 +
fs/btrfs/file-item.c |2 ++
fs/btrfs
Sano-san,
(2011/02/14 22:57), Yoshinori Sano wrote:
> 2011年2月14日8:57 Tsutomu Itoh :
>> (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 d
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
---
fs/btrfs/extent-tree.c |2 +-
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.
>
> Si
- The error code is returned in the place where the error can be
easily returned.
Signed-off-by: Tsutomu Itoh
---
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/inode.c
When btrfs_alloc_path() fails, btrfs_free_path() need not be called.
Therefore, it changes the branch ahead.
Signed-off-by: Tsutomu Itoh
---
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-rc3.test/fs/btrfs
(2011/02/02 14:07), Chris Samuel wrote:
> On 01/02/11 20:17, Tsutomu Itoh wrote:
>
>> Because NULL is returned when the memory allocation fails,
>> it is checked whether it is NULL.
>
> Were the callers modified to cope with these functions
> returning -ENOMEM ?
Because NULL is returned when the memory allocation fails,
it is checked whether it is NULL.
Signed-off-by: Tsutomu Itoh
---
fs/btrfs/extent-tree.c |2 ++
fs/btrfs/extent_io.c |2 ++
fs/btrfs/tree-log.c|6 ++
3 files changed, 10 insertions(+)
diff -urNp linux-2.6.38-rc2
Hi Chris,
(2011/01/29 6:53), Chris Mason wrote:
> Excerpts from Tsutomu Itoh's message of 2011-01-21 01:06:29 -0500:
>> (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 thin
Hi, Chris,
(2011/01/29 6:53), Chris Mason wrote:
> Excerpts from Tsutomu Itoh's message of 2011-01-21 01:06:29 -0500:
>> (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 thin
asily
returned.
As a long-term plan:
- BUG_ON() is reduced by using the forced-readonly framework, etc.
Signed-off-by: Tsutomu Itoh
---
fs/btrfs/disk-io.c |5 +
fs/btrfs/extent-tree.c |2 +-
fs/btrfs/inode.c | 24
fs/btrfs/ioctl.c |2 +-
fs/
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
---
fs/btrfs/ioctl.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -urNp linux-2.6.38-rc1/fs/btrfs/ioctl.c
linux-2.6.38-rc1
(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
(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.
The error check of btrfs_start_transaction() is added, and the mistake
of the error check on several places is corrected.
Signed-off-by: Tsutomu Itoh
---
fs/btrfs/extent-tree.c |7 +--
fs/btrfs/inode.c |1 +
fs/btrfs/ioctl.c | 10 --
fs/btrfs/relocation.c
(2011/01/12 9:25), Leonidas Spyropoulos wrote:
> Hey all,
>
> I have a weird error with my RAID 0 btrfs partition.
> Information for the partitions follow:
>
> # btrfs filesystem show
> failed to read /dev/sr0
> Label: none uuid: 1882b025-58e4-4287-98a3-9b772af0ad76
> Total devices 2 FS by
Should check if functions returns NULL or not.
Signed-off-by: Tsutomu Itoh
---
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/btrfs/ctree.c
index
In btrfs_read_fs_root_no_radix(), 'root' is not freed if
btrfs_search_slot() returns error.
Signed-off-by: Tsutomu Itoh
---
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-2.6.37-rc
(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 c
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
$ ls -i foo
266 foo
$ rm foo
$ touch bar
$ ls -
(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/bt
(2010/12/08 5:15), Chris Mason wrote:
> Excerpts from Mike Fedyk's message of 2010-12-07 15:07:08 -0500:
>> On Tue, Dec 7, 2010 at 11:29 AM, Chris Mason wrote:
>>> Excerpts from Mike Fedyk's message of 2010-12-07 14:16:55 -0500:
On Tue, Dec 7, 2010 at 10:44 AM, Chris Mason
wrote:
(2010/12/07 18:25), Li Zefan wrote:
> Tsutomu Itoh wrote:
>> Hi,
>>
>> I think that the disk allocation size of each file becomes a monotone
>> increase
>> when the file is made.
>> But, it sometimes return to 0. Is it correct?
>>
>
Hi,
I think that the disk allocation size of each file becomes a monotone increase
when the file is made.
But, it sometimes return to 0. Is it correct?
The result of the test at 2.6.37-rc4 is shown below.
(see inode no. 291)
# df -T /test14
FilesystemType 1K-blocks Used Ava
Hi,
I found 1 typo.
(2010/12/01 19:21), liubo wrote:
> Since there is a filesystem state, we should deal with it carefully at mount,
> umount and remount.
>
> - At mount, the FS state should be checked if there is error on these FS.
> If it does have, btrfsck is recommended.
> - At umount, th
1970 /test1
[after]
# date
Tue Nov 16 18:06:05 JST 2010
# mkfs.btrfs /dev/sdd10
# mount /dev/sdd10 /test1
# ls -ld /test1
dr-xr-xr-x 1 root root 0 Nov 16 18:06 /test1
Thanks,
Tsutomu
Signed-off-by: Tsutomu Itoh
---
utils.c |9 +
1 file changed, 9 insertions(+)
diff -urNp
Hi.
(2010/11/11 16:48), Helmut Hullen wrote:
Hallo, Hugo,
Du meintest am 10.11.10:
findfs LABEL=MM2
shows "/dev/sdd2" (the first partition)
file -s /dev/sdd2
file -s /dev/sdc3
shows "LABEL=MM2" for both partitions
mount LABEL=MM2 /srv/MM
doesn't work
201 - 297 of 297 matches
Mail list logo
