linux-toradex.git/drivers/md/bitmap.h, branch v3.2-rc5

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 bitmap: Revert DM dirty log hooks

2011-07-27T01:00:37+00:00

Revert most of commit e384e58549a2e9a83071ad80280c1a9053cfd84c
  md/bitmap: prepare for storing write-intent-bitmap via dm-dirty-log.

MD should not need to use DM's dirty log - we decided to use md's
bitmaps instead.

Keeping the DIV_ROUND_UP clean-ups that were part of commit
e384e58549a2e9a83071ad80280c1a9053cfd84c, however.

Signed-off-by: Jonathan Brassow 
Signed-off-by: NeilBrown

md/bitmap: remove unused fields from struct bitmap

2011-06-09T01:43:01+00:00

Get rid of ->syncchunk and ->counter_bits since they're never used.

Also discard COUNTER_BYTE_RATIO which is unused.

Signed-off-by: Namhyung Kim 
Signed-off-by: NeilBrown

Fix common misspellings

2011-03-31T14:26:23+00:00

Fixes generated by 'codespell' and manually reviewed.

Signed-off-by: Lucas De Marchi

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