On 9/8/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
So, what I want to do is:
* Mark the synced spare drive as working and in position 1
* Assemble the array without the unsynced spare and check if this
provides consistent data
* If it didnt, I want to mark the synced spare as
On 9/11/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On 9/8/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
So, what I want to do is:
* Mark the synced spare drive as working and in position 1
* Assemble the array without the unsynced spare and check if this
provides consistent data
Leon Avery wrote:
I've been using RAID for a long time, but have been using the old
raidtools. Having just discovered mdadm, I want to switch, but I'm
having trouble. I'm trying to figure out how to use mdadm to replace a
failed disk. Here is my /proc/mdstat:
Personalities :
Neil,
The following patches implement hardware accelerated raid5 for the Intel
Xscale® series of I/O Processors. The MD changes allow stripe
operations to run outside the spin lock in a work queue. Hardware
acceleration is achieved by using a dma-engine-aware work queue routine
instead of the
From: Dan Williams [EMAIL PROTECTED]
raid5_do_soft_block_ops consolidates all the stripe cache maintenance
operations into a single routine. The stripe operations are:
* copying data between the stripe cache and user application buffers
* computing blocks to save a disk access, or to recover a
From: Dan Williams [EMAIL PROTECTED]
Also brings the iop3xx registers in line with the format of the iop13xx
register definitions.
Signed-off-by: Dan Williams [EMAIL PROTECTED]
---
include/asm-arm/arch-iop32x/entry-macro.S |2
include/asm-arm/arch-iop32x/iop32x.h | 14 +
From: Dan Williams [EMAIL PROTECTED]
Signed-off-by: Dan Williams [EMAIL PROTECTED]
---
drivers/dma/dmaengine.c | 15
drivers/dma/ioatdma.c |6 +
include/linux/dmaengine.h | 56 +
3 files changed, 77 insertions(+), 0
From: Dan Williams [EMAIL PROTECTED]
Enable handle_stripe5 to pass off compute block operations to
raid5_do_soft_block_ops, formerly handled by compute_block.
Here are a few notes about the new flags R5_ComputeReq and
STRIPE_OP_COMPUTE_Recover:
Previously, when handle_stripe5 found a block that
From: Dan Williams [EMAIL PROTECTED]
Adds the platform device definitions and the architecture specific support
routines (i.e. register initialization and descriptor formats) for the
iop-adma driver.
Changelog:
* add support for 1k zero sum buffer sizes
* added dma/aau platform devices to
From: Dan Williams [EMAIL PROTECTED]
Enable handle_stripe5 to use the reconstruct write operations capability
for expansion operations.
However this does not move the copy operation associated with an expand to
the workqueue. First, it was difficult to find a clean way to pass the
parameters
From: Dan Williams [EMAIL PROTECTED]
Default virtual function that returns an error if the user attempts a
memcpy operation. An XOR engine is an example of a DMA engine that does
not support memcpy.
Signed-off-by: Dan Williams [EMAIL PROTECTED]
---
drivers/dma/dmaengine.c | 13 +
From: Dan Williams [EMAIL PROTECTED]
Change the backend dma driver API to accept a 'union dmaengine_addr'. The
intent is to be able to support a wide range of frontend address type
permutations without needing an equal number of function type permutations
on the backend.
Changelog:
* make the
From: Dan Williams [EMAIL PROTECTED]
dma_sync_wait is a common routine to live wait for a dma operation to
complete.
Signed-off-by: Dan Williams [EMAIL PROTECTED]
---
include/linux/dmaengine.h | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git
From: Dan Williams [EMAIL PROTECTED]
Allow a client to ensure that the dma channel it has selected can
dma to the specified buffer or page address. Also allow the client to
pre-map address ranges to be passed to the operations API.
Changelog:
* make the dmaengine api EXPORT_SYMBOL_GPL
* zero
From: Dan Williams [EMAIL PROTECTED]
Changelog:
* make the dmaengine api EXPORT_SYMBOL_GPL
* zero sum support should be standalone, not integrated into xor
Signed-off-by: Dan Williams [EMAIL PROTECTED]
---
drivers/dma/dmaengine.c | 15 ++
drivers/dma/ioatdma.c |5 +++
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]
Currently the iop3xx platform support code assumes that RedBoot is the
bootloader and has already initialized the ATU. Linux should handle this
initialization for three reasons:
1/ The memory map that RedBoot sets up is not optimal (page_to_dma and
From: Dan Williams [EMAIL PROTECTED]
Enable the dmaengine interface to allow multiple clients to share a
channel, and enable clients to request channels based on an operations
capability mask. This prepares the interface for use with the RAID5 client
and the future RAID6 client.
Multi-client
From: Dan Williams [EMAIL PROTECTED]
Enable handle_stripe5 to pass off check parity operations to
raid5_do_soft_block_ops formerly handled by compute_parity5.
Changelog:
* removed handle_check_operations5. All logic moved into handle_stripe5 so
that we do not need to go through the initiation
From: Dan Williams [EMAIL PROTECTED]
Enable handle_stripe5 to hand off the memory copy operations that satisfy
read requests to raid5_do_soft_blocks_ops, formerly this was handled in
line within handle_stripe5.
It adds a 'read' (past tense) pointer to the r5dev structure
to to track reads that
Dan Williams wrote:
From: Dan Williams [EMAIL PROTECTED]
raid5_do_soft_block_ops consolidates all the stripe cache maintenance
operations into a single routine. The stripe operations are:
* copying data between the stripe cache and user application buffers
* computing blocks to save a disk
From: Dan Williams [EMAIL PROTECTED]
Enable handle_stripe5 to pass off write operations to
raid5_do_soft_blocks_ops (which can be run as a workqueue). The operations
moved are reconstruct-writes and read-modify-writes formerly handled by
compute_parity5.
Changelog:
* moved
From: Dan Williams [EMAIL PROTECTED]
replaced by the workqueue implementation
Signed-off-by: Dan Williams [EMAIL PROTECTED]
---
drivers/md/raid5.c | 123
1 files changed, 0 insertions(+), 123 deletions(-)
diff --git a/drivers/md/raid5.c
Dan Williams wrote:
Neil,
The following patches implement hardware accelerated raid5 for the Intel
Xscale® series of I/O Processors. The MD changes allow stripe
operations to run outside the spin lock in a work queue. Hardware
acceleration is achieved by using a dma-engine-aware work queue
Dan Williams wrote:
From: Dan Williams [EMAIL PROTECTED]
Enable handle_stripe5 to pass off write operations to
raid5_do_soft_blocks_ops (which can be run as a workqueue). The operations
moved are reconstruct-writes and read-modify-writes formerly handled by
compute_parity5.
Changelog:
* moved
Dan Williams wrote:
@@ -759,8 +755,10 @@ #endif
device-common.device_memcpy_buf_to_buf = ioat_dma_memcpy_buf_to_buf;
device-common.device_memcpy_buf_to_pg = ioat_dma_memcpy_buf_to_pg;
device-common.device_memcpy_pg_to_pg = ioat_dma_memcpy_pg_to_pg;
-
Dan Williams wrote:
From: Dan Williams [EMAIL PROTECTED]
Default virtual function that returns an error if the user attempts a
memcpy operation. An XOR engine is an example of a DMA engine that does
not support memcpy.
Signed-off-by: Dan Williams [EMAIL PROTECTED]
---
Dan Williams wrote:
From: Dan Williams [EMAIL PROTECTED]
Changelog:
* make the dmaengine api EXPORT_SYMBOL_GPL
* zero sum support should be standalone, not integrated into xor
Signed-off-by: Dan Williams [EMAIL PROTECTED]
---
drivers/dma/dmaengine.c | 15 ++
drivers/dma/ioatdma.c
Dan Williams wrote:
From: Dan Williams [EMAIL PROTECTED]
Also brings the iop3xx registers in line with the format of the iop13xx
register definitions.
Signed-off-by: Dan Williams [EMAIL PROTECTED]
---
include/asm-arm/arch-iop32x/entry-macro.S |2
include/asm-arm/arch-iop32x/iop32x.h
On 9/11/06, Jeff Garzik [EMAIL PROTECTED] wrote:
Dan Williams wrote:
Neil,
The following patches implement hardware accelerated raid5 for the Intel
Xscale(r) series of I/O Processors. The MD changes allow stripe
operations to run outside the spin lock in a work queue. Hardware
Dan Williams wrote:
From: Dan Williams [EMAIL PROTECTED]
dma_sync_wait is a common routine to live wait for a dma operation to
complete.
Signed-off-by: Dan Williams [EMAIL PROTECTED]
---
include/linux/dmaengine.h | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff
On 9/11/06, Jeff Garzik [EMAIL PROTECTED] wrote:
Dan Williams wrote:
@@ -759,8 +755,10 @@ #endif
device-common.device_memcpy_buf_to_buf = ioat_dma_memcpy_buf_to_buf;
device-common.device_memcpy_buf_to_pg = ioat_dma_memcpy_buf_to_pg;
device-common.device_memcpy_pg_to_pg =
Jeff Are we really going to add a set of hooks for each DMA
Jeff engine whizbang feature?
Dan What's the alternative? But, also see patch 9 dmaengine:
Dan reduce backend address permutations it relieves some of this
Dan pain.
I guess you can pass an opcode into a common
Dan Williams wrote:
This is a frequently asked question, Alan Cox had the same one at OLS.
The answer is probably. The only complication I currently see is
where/how the stripe cache is maintained. With the IOPs its easy
because the DMA engines operate directly on kernel memory. With the
On 9/11/06, Jeff Garzik [EMAIL PROTECTED] wrote:
Dan Williams wrote:
This is a frequently asked question, Alan Cox had the same one at OLS.
The answer is probably. The only complication I currently see is
where/how the stripe cache is maintained. With the IOPs its easy
because the DMA
35 matches
Mail list logo
