On thu, 21 Jul 2011 20:53:24 -0400, Chris Mason wrote:
Hi everyone,
I just rebased Josef's enospc fixes into integration-test, it should fix
the warnings in extent-tree.c
>>>
>>> Unfortunately, I got the following messages.
>>>
>>>
>>> Jul 21 09:41:22 luna kernel: -
(2011/07/22 4:48), 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.
>
> do_chunk_alloc() a
Excerpts from Arne Jansen's message of 2011-07-21 01:46:55 -0400:
> On 21.07.2011 02:48, Tsutomu Itoh wrote:
> > (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,
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,
On 07/18/2011 10:29 AM, Jan Schmidt wrote:
> If you are on a 3.0 kernel, get the most current version of btrfs
> tools from Hugo's integration-20110705 branch at
> http://git.darksatanic.net/repo/btrfs-progs-unstable.git/ and do a
> scrub. -Jan
Thx Jan, I did. This is the result:
scrub status fo
Jan Schmidt writes:
> +
> +static long btrfs_ioctl_logical_to_ino(struct btrfs_root *root,
> + void __user *arg)
> +{
> + int ret = 0;
> + int size;
> + u64 extent_offset;
> + struct btrfs_ioctl_logical_ino_args *loi;
> + struct btrfs_data_co
Dealing with this seems trivial - the only caller of btrfs_balance() is
btrfs_ioctl() which passes the error code directly back to userspace. There
also isn't much state to unwind (if I'm wrong about this point, we can
always safely move the allocation to the top of btrfs_balance() anyway).
Signed
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.
do_chunk_alloc() also needed an update since it calls btrfs_alloc_ch
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, 6 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/extent-t
I moved the path allocation up a few lines to the top of the function so
that we couldn't get into the state where we've dropped delayed items and
the extent cache but fail due to -ENOMEM.
Signed-off-by: Mark Fasheh
---
fs/btrfs/inode.c |9 +
1 files changed, 5 insertions(+), 4 delet
btrfs_iget() also needed an update so that errors from btrfs_locked_inode()
are caught and bubbled back up.
Signed-off-by: Mark Fasheh
---
fs/btrfs/inode.c | 22 +-
1 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index a0f
The two ->process_func call sites in tree-log.c which were ignoring a return
code have also been updated to gracefully exit as well.
Signed-off-by: Mark Fasheh
---
fs/btrfs/tree-log.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btr
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 errors from it already so bubbling the
error u
Changelog:
- Updated patch 6 after review from Tsutomu Itoh
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
The set/clear bit and the extent split/merge hooks only ever return 0.
Changing them to return void simplifies the error handling cases later.
This patch changes the hook prototypes, the single implementation of each,
and the functions that call them to return void instead.
Since all four o
I'm running a Ceph Object Store with 3.0-rc7 and patches from Josef.
Occasionally I get the attached warning.
Everything seems to be working after this warning, but I am concerned...
Thanks,
Christian
[13319.808020] [ cut here ]
[13319.813284] WARNING: at fs/btrfs/inode.c
2011/7/18 Josef Bacik :
> On 07/18/2011 02:11 PM, Josef Bacik wrote:
>> Currently we reserve enough space to COW an entirely full btree for every
>> extent
>> we have reserved for an inode. This _sucks_, because you only need to COW
>> once,
>> and then everybody else is ok. Unfortunately we do
These helper functions iterate back references and call a function for each
backref. There is also a function to resolve an inode to a path in the
file system.
Signed-off-by: Jan Schmidt
---
fs/btrfs/Makefile |3 +-
fs/btrfs/backref.c | 748 +
the rest of the code uses int mirror_num, and so should scrub
Signed-off-by: Jan Schmidt
---
fs/btrfs/scrub.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index 59caf8f..41a0114 100644
--- a/fs/btrfs/scrub.c
+++ b/fs/btrfs/sc
While scrubbing, we may encounter various errors. Previously, a logical
address was printed to the log only. Now, all paths belonging to that
address are resolved and printed separately. That should work for hardlinks
as well as reflinks.
Signed-off-by: Jan Schmidt
---
fs/btrfs/scrub.c | 169 ++
This removes a FIXME comment and introduces the first part of nodatasum
fixup: It gets the corresponding inode for a logical address and triggers a
regular readpage for the corrupted sector.
Once we have on-the-fly error correction our error will be automatically
corrected. The correction code is
Fix the mirror_num determination in scrub_stripe. The rest of the scrub code
did not use mirror_num for anything important and that error went unnoticed.
The nodatasum fixup patch of this set depends on a correct mirror_num.
Signed-off-by: Jan Schmidt
---
fs/btrfs/scrub.c | 12 ++--
1
these ioctls make use of the new functions initially added for scrub. they
return all inodes belonging to a logical address (BTRFS_IOC_LOGICAL_INO) and
all paths belonging to an inode (BTRFS_IOC_INO_PATHS).
Signed-off-by: Jan Schmidt
---
fs/btrfs/ioctl.c | 134 ++
Currently, extent_read_full_page always assumes we are trying to read mirror
0, which generally is the best we can do. To add flexibility, pass it as a
parameter. This will be needed by scrub fixup code.
Signed-off-by: Jan Schmidt
---
fs/btrfs/disk-io.c |2 +-
fs/btrfs/extent_io.c |6 +
While testing raid-auto-repair patches I'm going to send out later, I just found
the very last bug in my current scrub patch series:
Changelog v4->v5:
- fixed a deadlock when fixup is taking longer while scrub is about to end
Original message follows:
This patch set intro
In normal operation, scrub is reading data sequentially in large portions.
In case of an i/o error, we try to find the corrupted area(s) by issuing
page sized read requests. With this commit we increment the
unverified_errors counter if all of the small size requests succeed.
Userland patches carr
Hi, Everyone
I found there is an bug in the code of the chunk allocation by reading
the code, That is:
If we allocate lots of the meta-data chunks or data chunks, and make
the system meta-data block group be full, then we can not allocate
any chunk for ever, even though there is lots of fre
27 matches
Mail list logo
