linux-stable.git/drivers/md/raid1.h, branch linux-3.4.y

md/raid1: ensure device failure recorded before write request returns.

2016-04-27T10:55:21+00:00

commit 55ce74d4bfe1b9444436264c637f39a152d1e5ac upstream.

When a write to one of the legs of a RAID1 fails, the failure is
recorded in the metadata of the other leg(s) so that after a restart
the data on the failed drive wont be trusted even if that drive seems
to be working again  (maybe a cable was unplugged).

Similarly when we record a bad-block in response to a write failure,
we must not let the write complete until the bad-block update is safe.

Currently there is no interlock between the write request completing
and the metadata update.  So it is possible that the write will
complete, the app will confirm success in some way, and then the
machine will crash before the metadata update completes.

This is an extremely small hole for a racy to fit in, but it is
theoretically possible and so should be closed.

So:
 - set MD_CHANGE_PENDING when requesting a metadata update for a
   failed device, so we can know with certainty when it completes
 - queue requests that experienced an error on a new queue which
   is only processed after the metadata update completes
 - call raid_end_bio_io() on bios in that queue when the time comes.

Signed-off-by: NeilBrown 
Signed-off-by: Zefan Li

md/raid1: Allocate spare to store replacement devices and their bios.

2011-12-22T23:17:56+00:00

In RAID1, a replacement is much like a normal device, so we just
double the size of the relevant arrays and look at all possible
devices for reads and writes.

This means that the array looks like it is now double the size in some
way - we need to be careful about that.
In particular, we checking if the array is still degraded while
creating a recovery request we need to only consider the first 'half'
- i.e. the real (non-replacement) devices.

Signed-off-by: NeilBrown

md: add proper write-congestion reporting to RAID1 and RAID10.

2011-10-11T05:50:01+00:00

RAID1 and RAID10 handle write requests by queuing them for handling by
a separate thread.  This is because when a write-intent-bitmap is
active we might need to update the bitmap first, so it is good to
queue a lot of writes, then do one big bitmap update for them all.

However writeback request devices to appear to be congested after a
while so it can make some guesstimate of throughput.  The infinite
queue defeats that (note that RAID5 has already has a finite queue so
it doesn't suffer from this problem).

So impose a limit on the number of pending write requests.  By default
it is 1024 which seems to be generally suitable.  Make it configurable
via module option just in case someone finds a regression.

Signed-off-by: NeilBrown

md/raid1: typedef removal: conf_t -> struct r1conf

2011-10-11T05:49:05+00:00

Signed-off-by: NeilBrown

md: remove typedefs: mirror_info_t -> struct mirror_info

2011-10-11T05:48:46+00:00

Signed-off-by: NeilBrown

md: remove typedefs: r10bio_t -> struct r10bio and r1bio_t -> struct r1bio

2011-10-11T05:48:43+00:00

Signed-off-by: NeilBrown

md: remove typedefs: mdk_thread_t -> struct md_thread

2011-10-11T05:48:23+00:00

Signed-off-by: NeilBrown

md: remove typedefs: mddev_t -> struct mddev

2011-10-11T05:47:53+00:00

Having mddev_t and 'struct mddev_s' is ugly and not preferred

Signed-off-by: NeilBrown

md: removing typedefs: mdk_rdev_t -> struct md_rdev

2011-10-11T05:45:26+00:00

The typedefs are just annoying. 'mdk' probably refers to 'md_k.h'
which used to be an include file that defined this thing.

Signed-off-by: NeilBrown

md/raid1: add documentation to r1_private_data_s data structure.

2011-10-07T03:22:33+00:00

There wasn't much and it is inconsistent.
Also rearrange fields to keep related fields together.

Reported-by: Aapo Laine 
Signed-off-by: NeilBrown