These patches are presented to further the discussion of raid5 write
performance and are not yet meant for mainline or -mm inclusion. Raz's
delayed-activation patch showed interesting results so it has been
ported/included in this series. The question to be answered is whether
the sequential
In write-through mode bi_end_io is called once writes to the data disk(s)
and the parity disk have completed.
In write-back mode bi_end_io is called immediately after data has been
copied into the stripe cache, which also causes the stripe to be marked
dirty. The STRIPE_DIRTY state implies that
struct stripe_head_state collects all the dynamic stripe-state information
that is calculated/tracked during calls to handle_stripe. This enables a
mechanism for handle_stripe functionality to be broken off into
subroutines.
Signed-off-by: Dan Williams [EMAIL PROTECTED]
---
drivers/md/raid5.c
struct stripe_cache_policy is introduced as an interface to enable multiple
caching policies. It adds several methods to be called when cache events
occur. See the definition of stripe_cache_policy in
include/linux/raid/raid5.h. This patch does not add any new caching
policies, it just moves
based on a patch by: Raz Ben-Jehuda(caro) [EMAIL PROTECTED]
---
drivers/md/raid5.c | 92 +---
include/linux/raid/raid5.h |5 ++
2 files changed, 90 insertions(+), 7 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index
-stable review patch. If anyone has any objections, please let us know.
--
From: Neil Brown [EMAIL PROTECTED]
If 'num_pages' were ever 1 more than a multiple of 8 (32bit platforms)
for of 16 (64 bit platforms). filemap_attr would be allocated one
'unsigned long' shorter than
In its current implementation write-back mode acknowledges writes before
they have reached non-volatile media.
which is basically normal for unix, no?
are you planning to support barriers? (which are the block system's way
of supporting filesystem atomicity).
-
To unsubscribe from this
From: Mark Hahn [mailto:[EMAIL PROTECTED]
In its current implementation write-back mode acknowledges writes
before
they have reached non-volatile media.
which is basically normal for unix, no?
I am referring to when bi_end_io is called on the bio submitted to MD.
Normally it is not
Dan Williams wrote:
In write-through mode bi_end_io is called once writes to the data disk(s)
and the parity disk have completed.
In write-back mode bi_end_io is called immediately after data has been
copied into the stripe cache, which also causes the stripe to be marked
dirty.
This is not
