Linux RAID subsystem development
 help / color / mirror / Atom feed
* Odd CPU usage in the last stage of a raid5 reshape
@ 2013-04-19  7:54 Goswin von Brederlow
  2013-04-21 22:28 ` NeilBrown
  0 siblings, 1 reply; 2+ messages in thread
From: Goswin von Brederlow @ 2013-04-19  7:54 UTC (permalink / raw)
  To: linux-raid

Hi,

I'm still reshaping a 2 disk raid5 to 3 disks. It has now progressed
past the 50% mark so all data has been reshaped. So now the kernel
simply writes zeroes (I assume) to all 3 disks. There are no more
reads, only writes.

Now what is odd is the cpu usage:

/proc/mdsata:
md0 : active raid5 sdd1[3] sdc1[2] sda1[0]
      3907015168 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
      [============>........]  reshape = 62.0% (2425537964/3907015168) finish=22
0.0min speed=112230K/sec

iostat -k 10:
Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda             834.40         0.00    103372.60          0    1033726
md0               0.00         0.00         0.00          0          0
sdc             813.90         0.00    104601.80          0    1046018
sdd             718.50         0.00    104499.40          0    1044994

top:
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
 2058 root      20   0     0    0    0 R   96  0.0   1106:40 md0_raid5
18379 root      20   0     0    0    0 R   50  0.0 324:11.19 md0_reshape

Is the kernel zero filling the raid device and computing the XOR of
zeroes for the parity blocks? Wouldn't it be less cpu consuming to
insert zero filled stripes directly into the stripe cache?

MfG
	Goswin

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Odd CPU usage in the last stage of a raid5 reshape
  2013-04-19  7:54 Odd CPU usage in the last stage of a raid5 reshape Goswin von Brederlow
@ 2013-04-21 22:28 ` NeilBrown
  0 siblings, 0 replies; 2+ messages in thread
From: NeilBrown @ 2013-04-21 22:28 UTC (permalink / raw)
  To: Goswin von Brederlow; +Cc: linux-raid

[-- Attachment #1: Type: text/plain, Size: 1643 bytes --]

On Fri, 19 Apr 2013 09:54:04 +0200 Goswin von Brederlow <goswin-v-b@web.de>
wrote:

> Hi,
> 
> I'm still reshaping a 2 disk raid5 to 3 disks. It has now progressed
> past the 50% mark so all data has been reshaped. So now the kernel
> simply writes zeroes (I assume) to all 3 disks. There are no more
> reads, only writes.
> 
> Now what is odd is the cpu usage:
> 
> /proc/mdsata:
> md0 : active raid5 sdd1[3] sdc1[2] sda1[0]
>       3907015168 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
>       [============>........]  reshape = 62.0% (2425537964/3907015168) finish=22
> 0.0min speed=112230K/sec
> 
> iostat -k 10:
> Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
> sda             834.40         0.00    103372.60          0    1033726
> md0               0.00         0.00         0.00          0          0
> sdc             813.90         0.00    104601.80          0    1046018
> sdd             718.50         0.00    104499.40          0    1044994
> 
> top:
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
>  2058 root      20   0     0    0    0 R   96  0.0   1106:40 md0_raid5
> 18379 root      20   0     0    0    0 R   50  0.0 324:11.19 md0_reshape
> 
> Is the kernel zero filling the raid device and computing the XOR of
> zeroes for the parity blocks? Wouldn't it be less cpu consuming to
> insert zero filled stripes directly into the stripe cache?
> 

Yes, the kernel is computing an XOR of the zeros to determine the parity
block.  This certainly could be optimised, but it is hardly a priority.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2013-04-21 22:28 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-04-19  7:54 Odd CPU usage in the last stage of a raid5 reshape Goswin von Brederlow
2013-04-21 22:28 ` NeilBrown

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox