<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/md, branch linux-2.6.16.y</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=linux-2.6.16.y</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=linux-2.6.16.y'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2007-08-23T00:13:17+00:00</updated>
<entry>
<title>md: avoid possible BUG_ON in md bitmap handling</title>
<updated>2007-08-23T00:13:17+00:00</updated>
<author>
<name>Neil Brown</name>
<email>neilb@suse.de</email>
</author>
<published>2007-08-23T00:13:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=646edb4b5b9c472944af7d6016722fa4895f3bca'/>
<id>urn:sha1:646edb4b5b9c472944af7d6016722fa4895f3bca</id>
<content type='text'>
md/bitmap tracks how many active write requests are pending on blocks
associated with each bit in the bitmap, so that it knows when it can clear
the bit (when count hits zero).

The counter has 14 bits of space, so if there are ever more than 16383, we
cannot cope.

Currently the code just calles BUG_ON as "all" drivers have request queue
limits much smaller than this.

However is seems that some don't.  Apparently some multipath configurations
can allow more than 16383 concurrent write requests.

So, in this unlikely situation, instead of calling BUG_ON we now wait
for the count to drop down a bit.  This requires a new wait_queue_head,
some waiting code, and a wakeup call.

Tested by limiting the counter to 20 instead of 16383 (writes go a lot slower
in that case...).

Signed-off-by: Neil Brown &lt;neilb@suse.de&gt;
Signed-off-by: Adrian Bunk &lt;bunk@kernel.org&gt;
</content>
</entry>
<entry>
<title>md: fix a few problems with the interface (sysfs and ioctl) to md</title>
<updated>2007-08-22T23:39:24+00:00</updated>
<author>
<name>Neil Brown</name>
<email>neilb@suse.de</email>
</author>
<published>2007-08-22T23:39:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4d5eb09cab94fac8cfb767617a4799220f1874ab'/>
<id>urn:sha1:4d5eb09cab94fac8cfb767617a4799220f1874ab</id>
<content type='text'>
While developing more functionality in mdadm I found some bugs in md...

- When we remove a device from an inactive array (write 'remove' to
  the 'state' sysfs file - see 'state_store') would should not
  update the superblock information - as we may not have
  read and processed it all properly yet.

- initialise all raid_disk entries to '-1' else the 'slot sysfs file
  will claim '0' for all devices in an array before the array is
  started.

- all '\n' not to be present at the end of words written to
  sysfs files

- when we use SET_ARRAY_INFO to set the md metadata version,
  set the flag to say that there is persistant metadata.

- allow GET_BITMAP_FILE to be called on an array that hasn't
  been started yet.

Signed-off-by: Neil Brown &lt;neilb@suse.de&gt;
Signed-off-by: Adrian Bunk &lt;bunk@kernel.org&gt;
</content>
</entry>
<entry>
<title>md: assorted md and raid1 one-liners</title>
<updated>2007-08-22T23:38:42+00:00</updated>
<author>
<name>Neil Brown</name>
<email>neilb@suse.de</email>
</author>
<published>2007-08-22T23:38:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b3188291b5c6a9f9c2d6da21ef3f6d02f47d6c2e'/>
<id>urn:sha1:b3188291b5c6a9f9c2d6da21ef3f6d02f47d6c2e</id>
<content type='text'>
Fix few bugs that meant that:
  - superblocks weren't alway written at exactly the right time (this
    could show up if the array was not written to - writting to the array
    causes lots of superblock updates and so hides these errors).

  - restarting device recovery after a clean shutdown (version-1 metadata
    only) didn't work as intended (or at all).

1/ Ensure superblock is updated when a new device is added.
2/ Remove an inappropriate test on MD_RECOVERY_SYNC in md_do_sync.
   The body of this if takes one of two branches depending on whether
   MD_RECOVERY_SYNC is set, so testing it in the clause of the if
   is wrong.
3/ Flag superblock for updating after a resync/recovery finishes.
4/ If we find the neeed to restart a recovery in the middle (version-1
   metadata only) make sure a full recovery (not just as guided by
   bitmaps) does get done.

Signed-off-by: Neil Brown &lt;neilb@suse.de&gt;
Signed-off-by: Adrian Bunk &lt;bunk@kernel.org&gt;
</content>
</entry>
<entry>
<title>md: fix some small races in bitmap plugging in raid5</title>
<updated>2007-08-22T23:06:28+00:00</updated>
<author>
<name>Neil Brown</name>
<email>neilb@suse.de</email>
</author>
<published>2007-08-22T23:06:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5405a10ecb16e5bfe696643cea821c49e99c4bbb'/>
<id>urn:sha1:5405a10ecb16e5bfe696643cea821c49e99c4bbb</id>
<content type='text'>
The comment gives more details, but I didn't quite have the sequencing write,
so there was room for races to leave bits unset in the on-disk bitmap for
short periods of time.

Signed-off-by: Neil Brown &lt;neilb@suse.de&gt;
Signed-off-by: Adrian Bunk &lt;bunk@kernel.org&gt;
</content>
</entry>
<entry>
<title>md: fix a plug/unplug race in raid5</title>
<updated>2007-08-22T23:02:57+00:00</updated>
<author>
<name>Neil Brown</name>
<email>neilb@suse.de</email>
</author>
<published>2007-08-22T23:02:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cc49f09942ea753b8587d3f01362ffd311c98a00'/>
<id>urn:sha1:cc49f09942ea753b8587d3f01362ffd311c98a00</id>
<content type='text'>
When a device is unplugged, requests are moved from one or two (depending on
whether a bitmap is in use) queues to the main request queue.

So whenever requests are put on either of those queues, we should make sure
the raid5 array is 'plugged'.  However we don't.  We currently plug the raid5
queue just before putting requests on queues, so there is room for a race.  If
something unplugs the queue at just the wrong time, requests will be left on
the queue and nothing will want to unplug them.  Normally something else will
plug and unplug the queue fairly soon, but there is a risk that nothing will.

Signed-off-by: Neil Brown &lt;neilb@suse.de&gt;
Signed-off-by: Adrian Bunk &lt;bunk@kernel.org&gt;
</content>
</entry>
<entry>
<title>md: fix resync speed calculation for restarted resyncs</title>
<updated>2007-08-22T22:57:45+00:00</updated>
<author>
<name>Neil Brown</name>
<email>neilb@suse.de</email>
</author>
<published>2007-08-22T22:57:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=26d0764d2bf7f6b8dcd5a99d85cc6b1c02b65da6'/>
<id>urn:sha1:26d0764d2bf7f6b8dcd5a99d85cc6b1c02b65da6</id>
<content type='text'>
We introduced 'io_sectors' recently so we could count the sectors that causes
io during resync separate from sectors which didn't cause IO - there can be a
difference if a bitmap is being used to accelerate resync.

However when a speed is reported, we find the number of sectors processed
recently by subtracting an oldish io_sectors count from a current
'curr_resync' count.  This is wrong because curr_resync counts all sectors,
not just io sectors.

So, add a field to mddev to store the curren io_sectors separately from
curr_resync, and use that in the calculations.

Signed-off-by: Neil Brown &lt;neilb@suse.de&gt;
Signed-off-by: Adrian Bunk &lt;bunk@kernel.org&gt;
</content>
</entry>
<entry>
<title>md: Allow re-add to work on array without bitmaps</title>
<updated>2007-08-22T22:56:48+00:00</updated>
<author>
<name>Neil Brown</name>
<email>neilb@suse.de</email>
</author>
<published>2007-08-22T22:56:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=32b268195c968892eec3cdb328e2594e379a658b'/>
<id>urn:sha1:32b268195c968892eec3cdb328e2594e379a658b</id>
<content type='text'>
When an array has a bitmap, a device can be removed and re-added and only
blocks changes since the removal (as recorded in the bitmap) will be resynced.

It should be possible to do a similar thing to arrays without bitmaps.  i.e.
if a device is removed and re-added and *no* changes have been made in the
interim, then the add should not require a resync.

This patch allows that option.  This means that when assembling an array one
device at a time (e.g.  during device discovery) the array can be enabled
read-only as soon as enough devices are available, but extra devices can still
be added without causing a resync.

Signed-off-by: Neil Brown &lt;neilb@suse.de&gt;
Signed-off-by: Adrian Bunk &lt;bunk@kernel.org&gt;
</content>
</entry>
<entry>
<title>md/bitmap: tidy up i_writecount handling in md/bitmap</title>
<updated>2007-08-11T23:09:29+00:00</updated>
<author>
<name>Neil Brown</name>
<email>neilb@suse.de</email>
</author>
<published>2007-08-11T23:09:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=287440c90e8bf967622072c0766d1c680d3c16ae'/>
<id>urn:sha1:287440c90e8bf967622072c0766d1c680d3c16ae</id>
<content type='text'>
md/bitmap modifies i_writecount of a bitmap file to make sure that no-one else
writes to it.  The reverting of the change is sometimes done twice, and there
is one error path where it is omitted.

This patch tidies that up.

Signed-off-by: Neil Brown &lt;neilb@suse.de&gt;
Signed-off-by: Adrian Bunk &lt;bunk@kernel.org&gt;
</content>
</entry>
<entry>
<title>md/bitmap: remove dead code from md/bitmap</title>
<updated>2007-08-11T23:07:37+00:00</updated>
<author>
<name>Neil Brown</name>
<email>neilb@suse.de</email>
</author>
<published>2007-08-11T23:07:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c6be40c9f51529d66e6b66910aa49693da795603'/>
<id>urn:sha1:c6be40c9f51529d66e6b66910aa49693da795603</id>
<content type='text'>
bitmap_active is never called, and the BITMAP_ACTIVE flag is never users or
tested, so discard them both.

Also remove some out-of-date 'todo' comments.

Signed-off-by: Neil Brown &lt;neilb@suse.de&gt;
Signed-off-by: Adrian Bunk &lt;bunk@kernel.org&gt;
</content>
</entry>
<entry>
<title>md/bitmap: remove unnecessary page reference manipulations from md/bitmap code</title>
<updated>2007-08-11T23:05:36+00:00</updated>
<author>
<name>Neil Brown</name>
<email>neilb@suse.de</email>
</author>
<published>2007-08-11T23:05:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b852d1f6463c5a9bf25ac324eac32e9cb1a2eaf7'/>
<id>urn:sha1:b852d1f6463c5a9bf25ac324eac32e9cb1a2eaf7</id>
<content type='text'>
md/bitmap gets a collection of pages representing the bitmap when it
initialises the bitmap, and puts all the references when discarding the
bitmap.

It also occasionally takes extra references without any good reason, and
sometimes drops them ...  though it doesn't always drop them, which can result
in a memory leak.

This patch removes the unnecessary 'get_page' calls, and the corresponding
'put_page' calls.

Signed-off-by: Neil Brown &lt;neilb@suse.de&gt;
Signed-off-by: Adrian Bunk &lt;bunk@kernel.org&gt;
</content>
</entry>
</feed>
