On Tue, 23 Jan 2007, Neil Brown wrote:
On Monday January 22, [EMAIL PROTECTED] wrote:
Justin Piszcz wrote:
My .config is attached, please let me know if any other information is
needed and please CC (lkml) as I am not on the list, thanks!
Running Kernel 2.6.19.2 on a MD RAID5
I can try and do this later this week possibly.
Justin.
On Tue, 23 Jan 2007, Neil Brown wrote:
On Monday January 22, [EMAIL PROTECTED] wrote:
Hi,
Yesterday I tried to increase the value of strip_cache_size to see if I can
get better performance or not. I increase the value from 2048
Justin Piszcz wrote:
[]
Is this a bug that can or will be fixed or should I disable pre-emption on
critical and/or server machines?
Disabling pre-emption on critical and/or server machines seems to be a good
idea in the first place. IMHO anyway.. ;)
/mjt
-
To unsubscribe from this list: send
On Tue, 23 Jan 2007, Michael Tokarev wrote:
Justin Piszcz wrote:
[]
Is this a bug that can or will be fixed or should I disable pre-emption on
critical and/or server machines?
Disabling pre-emption on critical and/or server machines seems to be a good
idea in the first place. IMHO
Justin Piszcz wrote:
On Tue, 23 Jan 2007, Michael Tokarev wrote:
Disabling pre-emption on critical and/or server machines seems to be a good
idea in the first place. IMHO anyway.. ;)
So bottom line is make sure not to use preemption on servers or else you
will get weird
3. mark the array read-only (mdadm -o)
You shouldn't be able to do this. It should only be possible to set
an array to read-only when it is not in use. The fact that you cannot
suggests something else if wrong.
Should I ? I assumed that mdadm -o could be run with a running used
array, and
On Tue, 23 Jan 2007, Michael Tokarev wrote:
Justin Piszcz wrote:
On Tue, 23 Jan 2007, Michael Tokarev wrote:
Disabling pre-emption on critical and/or server machines seems to be a good
idea in the first place. IMHO anyway.. ;)
So bottom line is make sure not to use preemption
I can try and do this later this week possibly.
Justin.
alt-sysrq-T or echo t /proc/sysrq-trigger can be really helpful to
diagnose this sort of problem (providing the system isn't so badly
stuck that the kernel logs don't get stored).
It is probably hitting a memory-allocation deadlock,
From: Dan Williams [EMAIL PROTECTED]
* introduce struct dma_async_tx_descriptor as a common field for all dmaengine
software descriptors
* convert the device_memcpy_* methods into separate prep, set src/dest, and
submit stages
* support capabilities beyond memcpy (xor, memset, xor zero sum,
From: Dan Williams [EMAIL PROTECTED]
async_tx is an api to describe a series of bulk memory
transfers/transforms. When possible these transactions are carried out by
asynchrounous dma engines. The api handles inter-transaction dependencies
and hides dma channel management from the client. When
From: Dan Williams [EMAIL PROTECTED]
handle_stripe sets STRIPE_OP_COMPUTE_BLK to request servicing from
raid5_run_ops. It also sets a flag for the block being computed to let
other parts of handle_stripe submit dependent operations. raid5_run_ops
guarantees that the compute operation completes
From: Dan Williams [EMAIL PROTECTED]
Prepare the raid5 implementation to use async_tx for running stripe
operations:
* biofill (copy data into request buffers to satisfy a read request)
* compute block (generate a missing block in the cache from the other
blocks)
* prexor (subtract existing data
From: Dan Williams [EMAIL PROTECTED]
Use raid5_run_ops to carry out the memory copies for a raid5 read request.
Signed-off-by: Dan Williams [EMAIL PROTECTED]
---
drivers/md/raid5.c | 40 +++-
1 files changed, 15 insertions(+), 25 deletions(-)
diff --git
From: Dan Williams [EMAIL PROTECTED]
The parity calculation for an expansion operation is the same as the
calculation performed at the end of a write with the caveat that all blocks
in the stripe are scheduled to be written. An expansion operation is
identified as a stripe with the POSTXOR flag
From: Dan Williams [EMAIL PROTECTED]
This is a driver for the iop DMA/AAU/ADMA units which are capable of pq_xor,
pq_update, pq_zero_sum, xor, dual_xor, xor_zero_sum, fill, copy+crc, and copy
operations.
Changelog:
* fixed a slot allocation bug in do_iop13xx_adma_xor that caused too few
slots to
From: Dan Williams [EMAIL PROTECTED]
replaced by raid5_run_ops
Signed-off-by: Dan Williams [EMAIL PROTECTED]
---
drivers/md/raid5.c | 124
1 files changed, 0 insertions(+), 124 deletions(-)
diff --git a/drivers/md/raid5.c
From: Dan Williams [EMAIL PROTECTED]
Each stripe has three flag variables to reflect the state of operations
(pending, ack, and complete).
-pending: set to request servicing in raid5_run_ops
-ack: set to reflect that raid5_runs_ops has seen this request
-complete: set when the operation is
From: Dan Williams [EMAIL PROTECTED]
handle_stripe sets STRIPE_OP_PREXOR, STRIPE_OP_BIODRAIN, STRIPE_OP_POSTXOR
to request a write to the stripe cache. raid5_run_ops is triggerred to run
and executes the request outside the stripe lock.
Signed-off-by: Dan Williams [EMAIL PROTECTED]
---
From: Dan Williams [EMAIL PROTECTED]
handle_stripe sets STRIPE_OP_CHECK to request a check operation in
raid5_run_ops. If raid5_run_ops is able to perform the check with a
dma engine the parity will be preserved in memory removing the need to
re-read it from disk, as is necessary in the
On Tuesday January 23, [EMAIL PROTECTED] wrote:
My question is then : what prevents the upper layer to open the array
read-write, submit a write and make the md code BUG_ON() ?
The theory is that when you tell an md array to become read-only, it
tells the block layer that it is read-only, and
On Tuesday January 23, [EMAIL PROTECTED] wrote:
I think your patch is not enough to slove the read_page error
completely. I think in the bitmap_init_from_disk we also need to check
the 'count' never exceeds the size of file before calling the
read_page function. How do your think about it.
On Tue, 23 Jan 2007 11:26:52 +1100
NeilBrown [EMAIL PROTECTED] wrote:
+ for (j = 0; j vcnt ; j++)
+
memcpy(page_address(sbio-bi_io_vec[j].bv_page),
+
On Tuesday January 23, [EMAIL PROTECTED] wrote:
On Tue, 23 Jan 2007 11:26:52 +1100
NeilBrown [EMAIL PROTECTED] wrote:
+ for (j = 0; j vcnt ; j++)
+
memcpy(page_address(sbio-bi_io_vec[j].bv_page),
+
23 matches
Mail list logo
