<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/md/raid1.c, branch v3.15.2</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v3.15.2</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v3.15.2'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2014-04-09T04:42:23+00:00</updated>
<entry>
<title>md/raid1: r1buf_pool_alloc: free allocate pages when subsequent allocation fails.</title>
<updated>2014-04-09T04:42:23+00:00</updated>
<author>
<name>NeilBrown</name>
<email>neilb@suse.de</email>
</author>
<published>2014-04-09T02:25:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=da1aab3dca9aa88ae34ca392470b8943159e25fe'/>
<id>urn:sha1:da1aab3dca9aa88ae34ca392470b8943159e25fe</id>
<content type='text'>
When performing a user-request check/repair (MD_RECOVERY_REQUEST is set)
on a raid1, we allocate multiple bios each with their own set of pages.

If the page allocations for one bio fails, we currently do *not* free
the pages allocated for the previous bios, nor do we free the bio itself.

This patch frees all the already-allocate pages, and makes sure that
all the bios are freed as well.

This bug can cause a memory leak which can ultimately OOM a machine.
It was introduced in 3.10-rc1.

Fixes: a07876064a0b73ab5ef1ebcf14b1cf0231c07858
Cc: Kent Overstreet &lt;koverstreet@google.com&gt;
Cc: stable@vger.kernel.org (3.10+)
Reported-by: Russell King - ARM Linux &lt;linux@arm.linux.org.uk&gt;
Signed-off-by: NeilBrown &lt;neilb@suse.de&gt;
</content>
</entry>
<entry>
<title>md/raid1: restore ability for check and repair to fix read errors.</title>
<updated>2014-02-05T01:26:04+00:00</updated>
<author>
<name>NeilBrown</name>
<email>neilb@suse.de</email>
</author>
<published>2014-02-05T01:17:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1877db75589a895bbdc4c4c3f23558e57b521141'/>
<id>urn:sha1:1877db75589a895bbdc4c4c3f23558e57b521141</id>
<content type='text'>
commit 30bc9b53878a9921b02e3b5bc4283ac1c6de102a
    md/raid1: fix bio handling problems in process_checks()

Move the bio_reset() to a point before where BIO_UPTODATE is checked,
so that check now always report that the bio is uptodate, even if it is not.

This causes process_check() to sometimes treat read-errors as
successful matches so the good data isn't written out.

This patch preserves the flag until it is needed.

Bug was introduced in 3.11, but backported to 3.10-stable (as it fixed
an even worse bug).  So suitable for any -stable since 3.10.

Reported-and-tested-by: Michael Tokarev &lt;mjt@tls.msk.ru&gt;
Cc: stable@vger.kernel.org (3.10+)
Fixed: 30bc9b53878a9921b02e3b5bc4283ac1c6de102a
Signed-off-by: NeilBrown &lt;neilb@suse.de&gt;
</content>
</entry>
<entry>
<title>Merge branch 'for-3.14/core' of git://git.kernel.dk/linux-block</title>
<updated>2014-01-30T19:19:05+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-01-30T19:19:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f568849edac8611d603e00bd6cbbcfea09395ae6'/>
<id>urn:sha1:f568849edac8611d603e00bd6cbbcfea09395ae6</id>
<content type='text'>
Pull core block IO changes from Jens Axboe:
 "The major piece in here is the immutable bio_ve series from Kent, the
  rest is fairly minor.  It was supposed to go in last round, but
  various issues pushed it to this release instead.  The pull request
  contains:

   - Various smaller blk-mq fixes from different folks.  Nothing major
     here, just minor fixes and cleanups.

   - Fix for a memory leak in the error path in the block ioctl code
     from Christian Engelmayer.

   - Header export fix from CaiZhiyong.

   - Finally the immutable biovec changes from Kent Overstreet.  This
     enables some nice future work on making arbitrarily sized bios
     possible, and splitting more efficient.  Related fixes to immutable
     bio_vecs:

        - dm-cache immutable fixup from Mike Snitzer.
        - btrfs immutable fixup from Muthu Kumar.

  - bio-integrity fix from Nic Bellinger, which is also going to stable"

* 'for-3.14/core' of git://git.kernel.dk/linux-block: (44 commits)
  xtensa: fixup simdisk driver to work with immutable bio_vecs
  block/blk-mq-cpu.c: use hotcpu_notifier()
  blk-mq: for_each_* macro correctness
  block: Fix memory leak in rw_copy_check_uvector() handling
  bio-integrity: Fix bio_integrity_verify segment start bug
  block: remove unrelated header files and export symbol
  blk-mq: uses page-&gt;list incorrectly
  blk-mq: use __smp_call_function_single directly
  btrfs: fix missing increment of bi_remaining
  Revert "block: Warn and free bio if bi_end_io is not set"
  block: Warn and free bio if bi_end_io is not set
  blk-mq: fix initializing request's start time
  block: blk-mq: don't export blk_mq_free_queue()
  block: blk-mq: make blk_sync_queue support mq
  block: blk-mq: support draining mq queue
  dm cache: increment bi_remaining when bi_end_io is restored
  block: fixup for generic bio chaining
  block: Really silence spurious compiler warnings
  block: Silence spurious compiler warnings
  block: Kill bio_pair_split()
  ...
</content>
</entry>
<entry>
<title>md/raid1: fix request counting bug in new 'barrier' code.</title>
<updated>2014-01-14T05:44:07+00:00</updated>
<author>
<name>NeilBrown</name>
<email>neilb@suse.de</email>
</author>
<published>2014-01-14T00:56:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=41a336e011887f73e7c879b60e1e3544045435cb'/>
<id>urn:sha1:41a336e011887f73e7c879b60e1e3544045435cb</id>
<content type='text'>
The new iobarrier implementation in raid1 (which keeps normal writes
and resync activity separate) counts every request what is not before
the current resync point in either next_window_requests or
current_window_requests.
It flags that the request is counted by setting -&gt;start_next_window.

allow_barrier follows this model exactly and decrements one of the
*_window_requests if and only if -&gt;start_next_window is set.

However wait_barrier(), which increments *_window_requests uses a
slightly different test for setting -.start_next_window (which is set
from the return value of this function).
So there is a possibility of the counts getting out of sync, and this
leads to the resync hanging.

So change wait_barrier() to return a non-zero value in exactly the
same cases that it increments *_window_requests.

But was introduced in 3.13-rc1.

Reported-by: Bruno Wolff III &lt;bruno@wolff.to&gt;
URL: https://bugzilla.kernel.org/show_bug.cgi?id=68061
Fixes: 79ef3a8aa1cb1523cc231c9a90a278333c21f761
Cc: majianpeng &lt;majianpeng@gmail.com&gt;
Signed-off-by: NeilBrown &lt;neilb@suse.de&gt;
</content>
</entry>
<entry>
<title>block: Abstract out bvec iterator</title>
<updated>2013-11-24T06:33:47+00:00</updated>
<author>
<name>Kent Overstreet</name>
<email>kmo@daterainc.com</email>
</author>
<published>2013-10-11T22:44:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4f024f3797c43cb4b73cd2c50cec728842d0e49e'/>
<id>urn:sha1:4f024f3797c43cb4b73cd2c50cec728842d0e49e</id>
<content type='text'>
Immutable biovecs are going to require an explicit iterator. To
implement immutable bvecs, a later patch is going to add a bi_bvec_done
member to this struct; for now, this patch effectively just renames
things.

Signed-off-by: Kent Overstreet &lt;kmo@daterainc.com&gt;
Cc: Jens Axboe &lt;axboe@kernel.dk&gt;
Cc: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: Paul Mackerras &lt;paulus@samba.org&gt;
Cc: "Ed L. Cashin" &lt;ecashin@coraid.com&gt;
Cc: Nick Piggin &lt;npiggin@kernel.dk&gt;
Cc: Lars Ellenberg &lt;drbd-dev@lists.linbit.com&gt;
Cc: Jiri Kosina &lt;jkosina@suse.cz&gt;
Cc: Matthew Wilcox &lt;willy@linux.intel.com&gt;
Cc: Geoff Levand &lt;geoff@infradead.org&gt;
Cc: Yehuda Sadeh &lt;yehuda@inktank.com&gt;
Cc: Sage Weil &lt;sage@inktank.com&gt;
Cc: Alex Elder &lt;elder@inktank.com&gt;
Cc: ceph-devel@vger.kernel.org
Cc: Joshua Morris &lt;josh.h.morris@us.ibm.com&gt;
Cc: Philip Kelleher &lt;pjk1939@linux.vnet.ibm.com&gt;
Cc: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Cc: "Michael S. Tsirkin" &lt;mst@redhat.com&gt;
Cc: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Cc: Jeremy Fitzhardinge &lt;jeremy@goop.org&gt;
Cc: Neil Brown &lt;neilb@suse.de&gt;
Cc: Alasdair Kergon &lt;agk@redhat.com&gt;
Cc: Mike Snitzer &lt;snitzer@redhat.com&gt;
Cc: dm-devel@redhat.com
Cc: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Cc: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Cc: linux390@de.ibm.com
Cc: Boaz Harrosh &lt;bharrosh@panasas.com&gt;
Cc: Benny Halevy &lt;bhalevy@tonian.com&gt;
Cc: "James E.J. Bottomley" &lt;JBottomley@parallels.com&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: "Nicholas A. Bellinger" &lt;nab@linux-iscsi.org&gt;
Cc: Alexander Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Chris Mason &lt;chris.mason@fusionio.com&gt;
Cc: "Theodore Ts'o" &lt;tytso@mit.edu&gt;
Cc: Andreas Dilger &lt;adilger.kernel@dilger.ca&gt;
Cc: Jaegeuk Kim &lt;jaegeuk.kim@samsung.com&gt;
Cc: Steven Whitehouse &lt;swhiteho@redhat.com&gt;
Cc: Dave Kleikamp &lt;shaggy@kernel.org&gt;
Cc: Joern Engel &lt;joern@logfs.org&gt;
Cc: Prasad Joshi &lt;prasadjoshi.linux@gmail.com&gt;
Cc: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Cc: KONISHI Ryusuke &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
Cc: Mark Fasheh &lt;mfasheh@suse.com&gt;
Cc: Joel Becker &lt;jlbec@evilplan.org&gt;
Cc: Ben Myers &lt;bpm@sgi.com&gt;
Cc: xfs@oss.sgi.com
Cc: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Cc: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: Len Brown &lt;len.brown@intel.com&gt;
Cc: Pavel Machek &lt;pavel@ucw.cz&gt;
Cc: "Rafael J. Wysocki" &lt;rjw@sisk.pl&gt;
Cc: Herton Ronaldo Krzesinski &lt;herton.krzesinski@canonical.com&gt;
Cc: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Guo Chao &lt;yan@linux.vnet.ibm.com&gt;
Cc: Tejun Heo &lt;tj@kernel.org&gt;
Cc: Asai Thambi S P &lt;asamymuthupa@micron.com&gt;
Cc: Selvan Mani &lt;smani@micron.com&gt;
Cc: Sam Bradshaw &lt;sbradshaw@micron.com&gt;
Cc: Wei Yongjun &lt;yongjun_wei@trendmicro.com.cn&gt;
Cc: "Roger Pau Monné" &lt;roger.pau@citrix.com&gt;
Cc: Jan Beulich &lt;jbeulich@suse.com&gt;
Cc: Stefano Stabellini &lt;stefano.stabellini@eu.citrix.com&gt;
Cc: Ian Campbell &lt;Ian.Campbell@citrix.com&gt;
Cc: Sebastian Ott &lt;sebott@linux.vnet.ibm.com&gt;
Cc: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Cc: Minchan Kim &lt;minchan@kernel.org&gt;
Cc: Jiang Liu &lt;jiang.liu@huawei.com&gt;
Cc: Nitin Gupta &lt;ngupta@vflare.org&gt;
Cc: Jerome Marchand &lt;jmarchand@redhat.com&gt;
Cc: Joe Perches &lt;joe@perches.com&gt;
Cc: Peng Tao &lt;tao.peng@emc.com&gt;
Cc: Andy Adamson &lt;andros@netapp.com&gt;
Cc: fanchaoting &lt;fanchaoting@cn.fujitsu.com&gt;
Cc: Jie Liu &lt;jeff.liu@oracle.com&gt;
Cc: Sunil Mushran &lt;sunil.mushran@gmail.com&gt;
Cc: "Martin K. Petersen" &lt;martin.petersen@oracle.com&gt;
Cc: Namjae Jeon &lt;namjae.jeon@samsung.com&gt;
Cc: Pankaj Kumar &lt;pankaj.km@samsung.com&gt;
Cc: Dan Magenheimer &lt;dan.magenheimer@oracle.com&gt;
Cc: Mel Gorman &lt;mgorman@suse.de&gt;6
</content>
</entry>
<entry>
<title>Merge tag 'md/3.13' of git://neil.brown.name/md</title>
<updated>2013-11-20T21:05:25+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2013-11-20T21:05:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6d6e352c80f22c446d933ca8103e02bac1f09129'/>
<id>urn:sha1:6d6e352c80f22c446d933ca8103e02bac1f09129</id>
<content type='text'>
Pull md update from Neil Brown:
 "Mostly optimisations and obscure bug fixes.
   - raid5 gets less lock contention
   - raid1 gets less contention between normal-io and resync-io during
     resync"

* tag 'md/3.13' of git://neil.brown.name/md:
  md/raid5: Use conf-&gt;device_lock protect changing of multi-thread resources.
  md/raid5: Before freeing old multi-thread worker, it should flush them.
  md/raid5: For stripe with R5_ReadNoMerge, we replace REQ_FLUSH with REQ_NOMERGE.
  UAPI: include &lt;asm/byteorder.h&gt; in linux/raid/md_p.h
  raid1: Rewrite the implementation of iobarrier.
  raid1: Add some macros to make code clearly.
  raid1: Replace raise_barrier/lower_barrier with freeze_array/unfreeze_array when reconfiguring the array.
  raid1: Add a field array_frozen to indicate whether raid in freeze state.
  md: Convert use of typedef ctl_table to struct ctl_table
  md/raid5: avoid deadlock when raid5 array has unack badblocks during md_stop_writes.
  md: use MD_RECOVERY_INTR instead of kthread_should_stop in resync thread.
  md: fix some places where mddev_lock return value is not checked.
  raid5: Retry R5_ReadNoMerge flag when hit a read error.
  raid5: relieve lock contention in get_active_stripe()
  raid5: relieve lock contention in get_active_stripe()
  wait: add wait_event_cmd()
  md/raid5.c: add proper locking to error path of raid5_start_reshape.
  md: fix calculation of stacking limits on level change.
  raid5: Use slow_path to release stripe when mddev-&gt;thread is null
</content>
</entry>
<entry>
<title>raid1: Rewrite the implementation of iobarrier.</title>
<updated>2013-11-19T04:19:18+00:00</updated>
<author>
<name>majianpeng</name>
<email>majianpeng@gmail.com</email>
</author>
<published>2013-11-15T06:55:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=79ef3a8aa1cb1523cc231c9a90a278333c21f761'/>
<id>urn:sha1:79ef3a8aa1cb1523cc231c9a90a278333c21f761</id>
<content type='text'>
There is an iobarrier in raid1 because of contention between normal IO and
resync IO.  It suspends all normal IO when resync/recovery happens.

However if normal IO is out side the resync window, there is no contention.
So this patch changes the barrier mechanism to only block IO that
could contend with the resync that is currently happening.

We partition the whole space into five parts.
|---------|-----------|------------|----------------|-------|
        start   next_resync   start_next_window    end_window

start + RESYNC_WINDOW = next_resync
next_resync + NEXT_NORMALIO_DISTANCE = start_next_window
start_next_window + NEXT_NORMALIO_DISTANCE = end_window

Firstly we introduce some concepts:

1 - RESYNC_WINDOW: For resync, there are 32 resync requests at most at the
      same time. A sync request is RESYNC_BLOCK_SIZE(64*1024).
      So the RESYNC_WINDOW is 32 * RESYNC_BLOCK_SIZE, that is 2MB.
2 - NEXT_NORMALIO_DISTANCE: the distance between next_resync
      and start_next_window.  It also indicates the distance between
      start_next_window and end_window.
      It is currently 3 * RESYNC_WINDOW_SIZE but could be tuned if
      this turned out not to be optimal.
3 - next_resync: the next sector at which we will do sync IO.
4 - start: a position which is at most RESYNC_WINDOW before
      next_resync.
5 - start_next_window:  a position which is NEXT_NORMALIO_DISTANCE
      beyond next_resync.  Normal-io after this position doesn't need to
      wait for resync-io to complete.
6 - end_window:  a position which is 2 * NEXT_NORMALIO_DISTANCE beyond
      next_resync.  This also doesn't need to wait, but is counted
      differently.
7 - current_window_requests:  the count of normalIO between
      start_next_window and end_window.
8 - next_window_requests: the count of normalIO after end_window.

NormalIO will be partitioned into four types:

NormIO1:  the end sector of bio is smaller or equal the start
NormIO2:  the start sector of bio larger or equal to end_window
NormIO3:  the start sector of bio larger or equal to
          start_next_window.
NormIO4:  the location between start_next_window and end_window

|--------|-----------|--------------------|----------------|-------------|
    | start   |   next_resync   |  start_next_window   |  end_window |
 NormIO1   NormIO4            NormIO4                NormIO3      NormIO2

For NormIO1, we don't need any io barrier.
For NormIO4, we used a similar approach to the original iobarrier
    mechanism.  The normalIO and resyncIO must be kept separate.
For NormIO2/3, we add two fields to struct r1conf: "current_window_requests"
    and "next_window_requests". They indicate the count of active
    requests in the two window.
    For these, we don't wait for resync io to complete.

For resync action, if there are NormIO4s, we must wait for it.
If not, we can proceed.
But if resync action reaches start_next_window and
current_window_requests &gt; 0 (that is there are NormIO3s), we must
wait until the current_window_requests becomes zero.
When current_window_requests becomes zero,  start_next_window also
moves forward. Then current_window_requests will replaced by
next_window_requests.

There is a problem which when and how to change from NormIO2 to
NormIO3.  Only then can sync action progress.

We add a field in struct r1conf "start_next_window".

A: if start_next_window == MaxSector, it means there are no NormIO2/3.
   So start_next_window = next_resync + NEXT_NORMALIO_DISTANCE
B: if current_window_requests == 0 &amp;&amp; next_window_requests != 0, it
   means start_next_window move to end_window

There is another problem which how to differentiate between
old NormIO2(now it is NormIO3) and NormIO2.
For example, there are many bios which are NormIO2 and a bio which is
NormIO3. NormIO3 firstly completed, so the bios of NormIO2 became NormIO3.

We add a field in struct r1bio "start_next_window".
This is used to record the position conf-&gt;start_next_window when the call
to wait_barrier() is made in make_request().

In allow_barrier(), we check the conf-&gt;start_next_window.
If r1bio-&gt;stat_next_window == conf-&gt;start_next_window, it means
there is no transition between NormIO2 and NormIO3.
If r1bio-&gt;start_next_window != conf-&gt;start_next_window, it mean
there was a transition between NormIO2 and NormIO3.  There can only
have been one transition.  So it only means the bio is old NormIO2.

For one bio, there may be many r1bio's. So we make sure
all the r1bio-&gt;start_next_window are the same value.
If we met blocked_dev in make_request(), it must call allow_barrier
and wait_barrier. So the former and the later value of
conf-&gt;start_next_window will be change.
If there are many r1bio's with differnet start_next_window,
for the relevant bio, it depend on the last value of r1bio.
It will cause error. To avoid this, we must wait for previous r1bios
to complete.

Signed-off-by: Jianpeng Ma &lt;majianpeng@gmail.com&gt;
Signed-off-by: NeilBrown &lt;neilb@suse.de&gt;
</content>
</entry>
<entry>
<title>raid1: Add some macros to make code clearly.</title>
<updated>2013-11-19T04:19:18+00:00</updated>
<author>
<name>majianpeng</name>
<email>majianpeng@gmail.com</email>
</author>
<published>2013-11-14T04:16:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8e005f7c0276317cfa8fcb0291a0df57f9ef832c'/>
<id>urn:sha1:8e005f7c0276317cfa8fcb0291a0df57f9ef832c</id>
<content type='text'>
In a subsequent patch, we'll use some const parameters.
Using macros will make the code clearly.

Signed-off-by: Jianpeng Ma &lt;majianpeng@gmail.com&gt;
Signed-off-by: NeilBrown &lt;neilb@suse.de&gt;
</content>
</entry>
<entry>
<title>raid1: Replace raise_barrier/lower_barrier with freeze_array/unfreeze_array when reconfiguring the array.</title>
<updated>2013-11-19T04:19:18+00:00</updated>
<author>
<name>majianpeng</name>
<email>majianpeng@gmail.com</email>
</author>
<published>2013-11-14T04:16:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=07169fd478ed2fbb3c894d524be9400658f16747'/>
<id>urn:sha1:07169fd478ed2fbb3c894d524be9400658f16747</id>
<content type='text'>
We used to use raise_barrier to suspend normal IO while we reconfigure
the array.  However raise_barrier will soon only suspend some normal
IO, not all.  So we need something else.
Change it to use freeze_array.
But freeze_array not only suspends normal io, it also suspends
resync io.
For the place where call raise_barrier for reconfigure, it isn't a
problem.

Signed-off-by: Jianpeng Ma &lt;majianpeng@gmail.com&gt;
Signed-off-by: NeilBrown &lt;neilb@suse.de&gt;
</content>
</entry>
<entry>
<title>raid1: Add a field array_frozen to indicate whether raid in freeze state.</title>
<updated>2013-11-19T04:19:18+00:00</updated>
<author>
<name>majianpeng</name>
<email>majianpeng@gmail.com</email>
</author>
<published>2013-11-14T04:16:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b364e3d048e49b1d177eb7ee7853e77aa0560464'/>
<id>urn:sha1:b364e3d048e49b1d177eb7ee7853e77aa0560464</id>
<content type='text'>
Because the following patch will rewrite the content between normal IO
and resync IO. So we used a parameter to indicate whether raid is in freeze
array.

Signed-off-by: Jianpeng Ma &lt;majianpeng@gmail.com&gt;
Signed-off-by: NeilBrown &lt;neilb@suse.de&gt;
</content>
</entry>
</feed>
