On Thu, 14 Jul 2011 21:58:46 -0700 (PDT) da...@lang.hm wrote:
> On Thu, 14 Jul 2011, Chris Mason wrote:
>
> > Excerpts from Ric Wheeler's message of 2011-07-14 02:57:54 -0400:
> >> On 07/14/2011 07:38 AM, NeilBrown wrote:
> >>> On Thu, 14 Jul 2011 07:02:22 +0100 Ric Wheeler
> >>> wrote:
> >>>
>
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
On Thu, 14 Jul 2011, Chris Mason wrote:
Excerpts from Ric Wheeler's message of 2011-07-14 02:57:54 -0400:
On 07/14/2011 07:38 AM, NeilBrown wrote:
On Thu, 14 Jul 2011 07:02:22 +0100 Ric Wheeler wrote:
I'm certainly open to suggestions and collaboration. Do you have in mind any
particular w
(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
>
On 07/15/2011 01:26 AM, Josef Bacik wrote:
> Hit this nice little deadlock. What happens is this
>
> __btrfs_end_transaction with throttle set, --use_count so it equals 0
> btrfs_commit_transaction
>
> btrfs_end_transaction --use_count so now its -1 <== BAD
> we just return and w
(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
Excerpts from Ric Wheeler's message of 2011-07-14 02:57:54 -0400:
> On 07/14/2011 07:38 AM, NeilBrown wrote:
> > On Thu, 14 Jul 2011 07:02:22 +0100 Ric Wheeler wrote:
> >
> >>> I'm certainly open to suggestions and collaboration. Do you have in mind
> >>> any
> >>> particular way to make the int
(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
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
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
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 Fasheh
---
fs/btrfs/volumes.c |6 --
1
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
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
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
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
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 the code is doing something like this:
path
On Thu, Jul 14, 2011 at 03:00:07PM -0700, 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:
Please ignore -
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
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 the code is doing something like this:
path
This is fairly trivial - btrfs_set_root_node() - always returns zero so we
can just make it void. All callers ignore the return code now anyway. I
also made sure to check that none of the functions that
btrfs_set_root_node() calls returns an error that we might have needed to
catch and pass back.
On 07/14/2011 03:27 AM, Christian Brunner wrote:
> 2011/7/13 Josef Bacik :
>> On 07/12/2011 11:20 AM, Christian Brunner wrote:
>>> 2011/6/7 Josef Bacik :
On 06/06/2011 09:39 PM, Miao Xie wrote:
> On fri, 03 Jun 2011 14:46:10 -0400, Josef Bacik wrote:
>> I got a lot of these when runnin
On Thu, Jul 14, 2011 at 12:50 PM, John Stoffel wrote:
>> "Alasdair" == Alasdair G Kergon writes:
>
> Alasdair> On Thu, Jul 14, 2011 at 04:38:36PM +1000, Neil Brown wrote:
>>> It might make sense for a device to be able to report what the maximum
>>> 'N' supported is... that might make stacke
On Thu, 14 Jul 2011, John Stoffel wrote:
Alasdair> I'll just say that any solution ought to be stackable.
I've been mulling this over too and wondering how you'd handle this,
because upper layers really can't peak down into lower layers easily.
As far as I understand things.
So if you have btr
On Wed, Jun 29, 2011 at 3:47 AM, A. James Lewis wrote:
> Is there a possibility that one could have a 3 disk RAID5 array, and
> then add a 4th disk and then do a balance, growing the RAID5 onto 4
> disks and gaining the space still with RAID5? It seems that to be
> consistent, BTRFS would have t
> "Alasdair" == Alasdair G Kergon writes:
Alasdair> On Thu, Jul 14, 2011 at 04:38:36PM +1000, Neil Brown wrote:
>> It might make sense for a device to be able to report what the maximum
>> 'N' supported is... that might make stacked raid easier to manage...
Alasdair> I'll just say that any
reserved_bytes is not used for anything in the inode, remove it.
Signed-off-by: Josef Bacik
---
fs/btrfs/btrfs_inode.h |5 -
fs/btrfs/extent-tree.c |2 --
fs/btrfs/inode.c |1 -
3 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs
Moving things around to give us better packing in the btrfs_inode. This reduces
the size of our inode by 8 bytes. Thanks,
Signed-off-by: Josef Bacik
---
fs/btrfs/btrfs_inode.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs_
On 07/14/2011 03:27 AM, Christian Brunner wrote:
> 2011/7/13 Josef Bacik :
>> On 07/12/2011 11:20 AM, Christian Brunner wrote:
>>> 2011/6/7 Josef Bacik :
On 06/06/2011 09:39 PM, Miao Xie wrote:
> On fri, 03 Jun 2011 14:46:10 -0400, Josef Bacik wrote:
>> I got a lot of these when runnin
Hit this nice little deadlock. What happens is this
__btrfs_end_transaction with throttle set, --use_count so it equals 0
btrfs_commit_transaction
btrfs_end_transaction --use_count so now its -1 <== BAD
we just return and wait on the transaction
This is bad because we just retur
On Thu, Jul 14, 2011 at 04:38:36PM +1000, Neil Brown wrote:
> It might make sense for a device to be able to report what the maximum
> 'N' supported is... that might make stacked raid easier to manage...
I'll just say that any solution ought to be stackable.
This means understanding both that the
On 07/14/2011 08:38 AM, NeilBrown wrote:
> On Thu, 14 Jul 2011 07:02:22 +0100 Ric Wheeler wrote:
>
>>> I'm certainly open to suggestions and collaboration. Do you have in mind
>>> any
>>> particular way to make the interface richer??
>>>
>>> NeilBrown
>>
>> Hi Neil,
>>
>> I know that Chris has
On 07/14/2011 03:27 AM, Christian Brunner wrote:
> 2011/7/13 Josef Bacik :
>> On 07/12/2011 11:20 AM, Christian Brunner wrote:
>>> 2011/6/7 Josef Bacik :
On 06/06/2011 09:39 PM, Miao Xie wrote:
> On fri, 03 Jun 2011 14:46:10 -0400, Josef Bacik wrote:
>> I got a lot of these when runnin
When xfstests 224 was running, the box was panic, and i got this message:
[ 1998.327235] =
[ 1998.329940] [ INFO: possible recursive locking detected ]
[ 1998.329940] 2.6.39+ #3
[ 1998.329940] -
[ 1998.329940]
On Thu, 14 Jul 2011 11:37:41 +0200 Jan Schmidt
wrote:
> Hi Neil,
>
> On 14.07.2011 08:38, NeilBrown wrote:
> > I imagine a new field in 'struct bio' which was normally zero but could be
> > some small integer. It is only meaningful for read.
> > When 0 it means "get this data way you like".
> >
Hi Neil,
On 14.07.2011 08:38, NeilBrown wrote:
> I imagine a new field in 'struct bio' which was normally zero but could be
> some small integer. It is only meaningful for read.
> When 0 it means "get this data way you like".
> When non-zero it means "get this data using method N", where the diff
2011/7/13 Josef Bacik :
> On 07/12/2011 11:20 AM, Christian Brunner wrote:
>> 2011/6/7 Josef Bacik :
>>> On 06/06/2011 09:39 PM, Miao Xie wrote:
On fri, 03 Jun 2011 14:46:10 -0400, Josef Bacik wrote:
> I got a lot of these when running stress.sh on my test box
>
>
>
> This
36 matches
Mail list logo
