On 07/14/2011 06:56 AM, NeilBrown wrote:
On Wed, 29 Jun 2011 10:29:53 +0100 Ric Wheelerrwhee...@redhat.com wrote:
On 06/27/2011 07:46 AM, NeilBrown wrote:
On Thu, 23 Jun 2011 12:53:37 +0200 Nico Schottelius
nico-lkml-20110...@schottelius.org wrote:
Good morning devs,
I'm wondering
On Thu, 14 Jul 2011 07:02:22 +0100 Ric Wheeler rwhee...@redhat.com 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 a very specific set of use cases for
On 07/14/2011 07:38 AM, NeilBrown wrote:
On Thu, 14 Jul 2011 07:02:22 +0100 Ric Wheelerrwhee...@redhat.com 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 a very
On 14.07.2011 08:02, Ric Wheeler wrote:
On 07/14/2011 06:56 AM, NeilBrown wrote:
I'm certainly open to suggestions and collaboration. Do you have in
mind any
particular way to make the interface richer??
If a file system uses checksumming or other data corruption detection
bits, it can detect
2011/7/13 Josef Bacik jo...@redhat.com:
On 07/12/2011 11:20 AM, Christian Brunner wrote:
2011/6/7 Josef Bacik jo...@redhat.com:
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 is
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 different
On Thu, 14 Jul 2011 11:37:41 +0200 Jan Schmidt list.bt...@jan-o-sch.net
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
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 07/14/2011 03:27 AM, Christian Brunner wrote:
2011/7/13 Josef Bacik jo...@redhat.com:
On 07/12/2011 11:20 AM, Christian Brunner wrote:
2011/6/7 Josef Bacik jo...@redhat.com:
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
On 07/14/2011 08:38 AM, NeilBrown wrote:
On Thu, 14 Jul 2011 07:02:22 +0100 Ric Wheeler rwhee...@redhat.com 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 a
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
Hit this nice little deadlock. What happens is this
__btrfs_end_transaction with throttle set, --use_count so it equals 0
btrfs_commit_transaction
somebody else actually manages to start the commit
btrfs_end_transaction --use_count so now its -1 == BAD
we just return and wait on
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 jo...@redhat.com
---
fs/btrfs/btrfs_inode.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/btrfs_inode.h
reserved_bytes is not used for anything in the inode, remove it.
Signed-off-by: Josef Bacik jo...@redhat.com
---
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
Alasdair == Alasdair G Kergon a...@redhat.com 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
On Wed, Jun 29, 2011 at 3:47 AM, A. James Lewis ja...@fsck.co.uk 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
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
On Thu, Jul 14, 2011 at 12:50 PM, John Stoffel j...@stoffel.org wrote:
Alasdair == Alasdair G Kergon a...@redhat.com 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
On 07/14/2011 03:27 AM, Christian Brunner wrote:
2011/7/13 Josef Bacik jo...@redhat.com:
On 07/12/2011 11:20 AM, Christian Brunner wrote:
2011/6/7 Josef Bacik jo...@redhat.com:
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
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
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 -
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 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
btrfs_iget() also needed an update so that errors from btrfs_locked_inode()
are caught and bubbled back up.
Signed-off-by: Mark Fasheh mfas...@suse.com
---
fs/btrfs/inode.c | 22 +-
1 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/inode.c
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 changed, 6 insertions(+), 2 deletions(-)
diff --git
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 mfas...@suse.com
---
fs/btrfs/volumes.c
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 mfas...@suse.com
---
fs/btrfs/tree-log.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git
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 mfas...@suse.com
---
fs/btrfs/inode.c |9 +
1 files changed, 5
(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
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 Wheelerrwhee...@redhat.com wrote:
I'm certainly open to suggestions and collaboration. Do you have in mind
any
particular way to make the
(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
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 Wheelerrwhee...@redhat.com wrote:
I'm certainly open to suggestions and collaboration. Do you have in
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
34 matches
Mail list logo
