linux-toradex.git/drivers/md/bitmap.h, branch v2.6.39-rc2

md: use sector_t in bitmap_get_counter

2010-10-28T06:32:26+00:00

bitmap_get_counter returns the number of sectors covered
by the counter in a pass-by-reference variable.
In some cases this can be very large, so make it a sector_t
for safety.

Signed-off-by: NeilBrown

md/bitmap: separate out loading a bitmap from initialising the structures.

2010-07-26T03:21:34+00:00

dm makes this distinction between ->ctr and ->resume, so we need to
too.

Also get the new bitmap_load to clear out the bitmap first, as this is
most consistent with the dm suspend/resume approach

Signed-off-by: NeilBrown

md/bitmap: prepare for storing write-intent-bitmap via dm-dirty-log.

2010-07-26T03:21:34+00:00

This allows md/raid5 to fully work as a dm target.

Normally md uses a 'filemap' which contains a list of pages of bits
each of which may be written separately.
dm-log uses and all-or-nothing approach to writing the log, so
when using a dm-log, ->filemap is NULL and the flags normally stored
in filemap_attr are stored in ->logattrs instead.



Signed-off-by: NeilBrown

md/raid1: delay reads that could overtake behind-writes.

2010-05-18T05:27:57+00:00

When a raid1 array is configured to support write-behind
on some devices, it normally only reads from other devices.
If all devices are write-behind (because the rest have failed)
it is possible for a read request to be serviced before a
behind-write request, which would appear as data corruption.

So when forced to read from a WriteMostly device, wait for any
write-behind to complete, and don't start any more behind-writes.

Signed-off-by: NeilBrown

md: expose max value of behind writes counter

2010-05-18T05:27:46+00:00

Keep track of the maximum number of concurrent write-behind requests
for an md array and exposed this number in sysfs at
   md/bitmap/max_backlog_used

Writing any value to this file will clear it.

This allows userspace to be involved in tuning bitmap/backlog.

Signed-off-by: Paul Clements 
Signed-off-by: NeilBrown

md: Support write-intent bitmaps with externally managed metadata.

2009-12-14T01:51:41+00:00

In this case, the metadata needs to not be in the same
sector as the bitmap.
md will not read/write any bitmap metadata.  Config must be
done via sysfs and when a recovery makes the array non-degraded
again, writing 'true' to 'bitmap/can_clear' will allow bits in
the bitmap to be cleared again.

Signed-off-by: NeilBrown

md: move offset, daemon_sleep and chunksize out of bitmap structure

2009-12-14T01:51:41+00:00

... and into bitmap_info.  These are all configuration parameters
that need to be set before the bitmap is created.

Signed-off-by: NeilBrown

md/bitmap: protect against bitmap removal while being updated.

2009-12-14T01:49:46+00:00

A write intent bitmap can be removed from an array while the
array is active.
When this happens, all IO is suspended and flushed before the
bitmap is removed.
However it is possible that bitmap_daemon_work is still running to
clear old bits from the bitmap.  If it is, it can dereference the
bitmap after it has been freed.

So introduce a new mutex to protect bitmap_daemon_work and get it
before destroying a bitmap.

This is suitable for any current -stable kernel.

Signed-off-by: NeilBrown 
Cc: stable@kernel.org

md: move headers out of include/linux/raid/

2009-03-31T03:27:03+00:00

Move the headers with the local structures for the disciplines and
bitmap.h into drivers/md/ so that they are more easily grepable for
hacking and not far away.  md.h is left where it is for now as there
are some uses from the outside.

Signed-off-by: Christoph Hellwig 
Signed-off-by: NeilBrown