Does "--write-behind=" have to be done at create time?

Does "--write-behind=" have to be done at create time?

[Ian Dall]

I was wanting to try out the "--write-behind" option. I have a raid1
with bitmaps and write-mostly enabled, which are all the pre-requisites,
I think.

It would be nice if you could tweak this parameter on a live array, but
failing that, it is hard to see why it couldn't be done at assemble
time. mdadm wont let me though.

Is this a fundamental limitation?

A related question, if I do recreate the same array, with exactly the
same parameters (except for the write-behind value) will my data still
be OK?


-- 
Ian Dall <ian@beware.dropbear.id.au>

Re: Does "--write-behind=" have to be done at create time?

[Ian Dall]

On Thu, 2007-06-28 at 23:22 +0930, Ian Dall wrote:
> I was wanting to try out the "--write-behind" option. I have a raid1
> with bitmaps and write-mostly enabled, which are all the pre-requisites,
> I think.
> 
> It would be nice if you could tweak this parameter on a live array, but
> failing that, it is hard to see why it couldn't be done at assemble
> time. mdadm wont let me though.
> 
> Is this a fundamental limitation?

Looking through the mdadm source code it seems like


		case O(BUILD, WriteBehind):
		case O(CREATE, WriteBehind): /* write-behind mode */

could be changed to 

		case O(GROW, WriteBehind):
		case O(BUILD, WriteBehind):
		case O(CREATE, WriteBehind): /* write-behind mode */

and everything would be OK. I am completely new to this code though, so
I am I missing something?

If you already had a bitmap you would need to remove it first
(--bitmap=none) and then grow it back with writebehind set.

Ian

-- 
Ian Dall <ian@beware.dropbear.id.au>

Proposed enhancement to mdadm: Allow "--write-behind=" to be done in grow mode.

[Ian Dall]

There doesn't seem to be any designated place to send bug reports and
feature requests to mdadm, so I hope I am doing the right thing by
sending it here.

I have a small patch to mdamd which allows the write-behind amount to be
set a array grow time (instead of currently only at grow or create
time). I have tested this fairly extensively on some arrays built out of
loop back devices, and once on a real live array. I haven't lot any data
and it seems to work OK, though it is possible I am missing something.

--- mdadm-2.6.1/mdadm.c.writebehind	2006-12-21 16:12:50.000000000 +1030
+++ mdadm-2.6.1/mdadm.c	2007-06-30 13:16:22.000000000 +0930
@@ -827,6 +827,7 @@
 			bitmap_chunk = bitmap_chunk ? bitmap_chunk * 1024 : 512;
 			continue;
 
+		case O(GROW, WriteBehind):
 		case O(BUILD, WriteBehind):
 		case O(CREATE, WriteBehind): /* write-behind mode */
 			write_behind = DEFAULT_MAX_WRITE_BEHIND;


-- 
Ian Dall <ian@beware.dropbear.id.au>

Re: Proposed enhancement to mdadm: Allow "--write-behind=" to be done in grow mode.

[David Greaves]

Ian Dall wrote:
> There doesn't seem to be any designated place to send bug reports and
> feature requests to mdadm, so I hope I am doing the right thing by
> sending it here.
> 
> I have a small patch to mdamd which allows the write-behind amount to be
> set a array grow time (instead of currently only at grow or create
> time). I have tested this fairly extensively on some arrays built out of
> loop back devices, and once on a real live array. I haven't lot any data
> and it seems to work OK, though it is possible I am missing something.

Sounds like a useful feature...

Did you test the bitmap cases you mentioned?

David

Re: Proposed enhancement to mdadm: Allow "--write-behind=" to be done in grow mode.

[Ian Dall]

On Tue, 2007-07-03 at 15:03 +0100, David Greaves wrote:
> Ian Dall wrote:
> > There doesn't seem to be any designated place to send bug reports and
> > feature requests to mdadm, so I hope I am doing the right thing by
> > sending it here.
> > 
> > I have a small patch to mdamd which allows the write-behind amount to be
> > set a array grow time (instead of currently only at grow or create
> > time). I have tested this fairly extensively on some arrays built out of
> > loop back devices, and once on a real live array. I haven't lot any data
> > and it seems to work OK, though it is possible I am missing something.
> 
> Sounds like a useful feature...
> 
> Did you test the bitmap cases you mentioned?

Yes. And I can use mdadm -X to see that the write behind parameter is
set in the superblock. I don't know any way to monitor how much the
write behind feature is being used though.

My motivation was for doing this was to enable me to experiment to see
how effective it is. Currently I have a Raid 0 array across 3 very fast
(15k rpm) scsi disks. This array is mirrored by a single large vanilla
ata (7.2k rpm) disk. I figure that the read performance of the
combination is basically the read performance of the Raid 0, and the
sustained write performance is basically that of the ata disk, which is
about 6:1 read to write speed. I also see typically about 6 times the
read traffic to write traffic. So I figure it should be close to optimal
IF the bursts of write activity are not too long.

Does anyone know how I can monitor the number of pending writes? Where
are these queued? Are they simply stuck on the block device queue (and I
could see with iostat) or does the md device maintain its own special
queue for this?


Ian
-- 
Ian Dall <ian@beware.dropbear.id.au>

Re: Proposed enhancement to mdadm: Allow "--write-behind=" to be done in grow mode.

[Bill Davidsen]

Ian Dall wrote:
> On Tue, 2007-07-03 at 15:03 +0100, David Greaves wrote:
>   
>> Ian Dall wrote:
>>     
>>> There doesn't seem to be any designated place to send bug reports and
>>> feature requests to mdadm, so I hope I am doing the right thing by
>>> sending it here.
>>>
>>> I have a small patch to mdamd which allows the write-behind amount to be
>>> set a array grow time (instead of currently only at grow or create
>>> time). I have tested this fairly extensively on some arrays built out of
>>> loop back devices, and once on a real live array. I haven't lot any data
>>> and it seems to work OK, though it is possible I am missing something.
>>>       
>> Sounds like a useful feature...
>>
>> Did you test the bitmap cases you mentioned?
>>     
>
> Yes. And I can use mdadm -X to see that the write behind parameter is
> set in the superblock. I don't know any way to monitor how much the
> write behind feature is being used though.
>
> My motivation was for doing this was to enable me to experiment to see
> how effective it is. Currently I have a Raid 0 array across 3 very fast
> (15k rpm) scsi disks. This array is mirrored by a single large vanilla
> ata (7.2k rpm) disk. I figure that the read performance of the
> combination is basically the read performance of the Raid 0, and the
> sustained write performance is basically that of the ata disk, which is
> about 6:1 read to write speed. I also see typically about 6 times the
> read traffic to write traffic. So I figure it should be close to optimal
> IF the bursts of write activity are not too long.
>
> Does anyone know how I can monitor the number of pending writes? Where
> are these queued? Are they simply stuck on the block device queue (and I
> could see with iostat) or does the md device maintain its own special
> queue for this?
>   
Sort of... you can look at the stats in /proc/diskstats while you do a 
write burst. You should be able to note the increasing number of blocks 
written to the fast disks vs. the slow, and thereby see how behind the 
slow one gets.

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

Re: Proposed enhancement to mdadm: Allow "--write-behind=" to be done in grow mode.

[Bill Davidsen]

Ian Dall wrote:
> On Tue, 2007-07-03 at 15:03 +0100, David Greaves wrote:
>   
>> Ian Dall wrote:
>>     
>>> There doesn't seem to be any designated place to send bug reports and
>>> feature requests to mdadm, so I hope I am doing the right thing by
>>> sending it here.
>>>
>>> I have a small patch to mdamd which allows the write-behind amount to be
>>> set a array grow time (instead of currently only at grow or create
>>> time). I have tested this fairly extensively on some arrays built out of
>>> loop back devices, and once on a real live array. I haven't lot any data
>>> and it seems to work OK, though it is possible I am missing something.
>>>       
>> Sounds like a useful feature...
>>
>> Did you test the bitmap cases you mentioned?
>>     
>
> Yes. And I can use mdadm -X to see that the write behind parameter is
> set in the superblock. I don't know any way to monitor how much the
> write behind feature is being used though.
>
> My motivation was for doing this was to enable me to experiment to see
> how effective it is. Currently I have a Raid 0 array across 3 very fast
> (15k rpm) scsi disks. This array is mirrored by a single large vanilla
> ata (7.2k rpm) disk. I figure that the read performance of the
> combination is basically the read performance of the Raid 0, and the
> sustained write performance is basically that of the ata disk, which is
> about 6:1 read to write speed. I also see typically about 6 times the
> read traffic to write traffic. So I figure it should be close to optimal
> IF the bursts of write activity are not too long.
>
> Does anyone know how I can monitor the number of pending writes? Where
> are these queued? Are they simply stuck on the block device queue (and I
> could see with iostat) or does the md device maintain its own special
> queue for this?
>   

I didn't mention, one of the parameters for the drive (not partition) in 
diskstats is the number of I/O in progress, field nine of the report for 
the drive as a whole. Hope that's all you need.

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

Re: Proposed enhancement to mdadm: Allow "--write-behind=" to be done in grow mode.

[Neil Brown]

On Tuesday July 3, ian@beware.dropbear.id.au wrote:
> There doesn't seem to be any designated place to send bug reports and
> feature requests to mdadm, so I hope I am doing the right thing by
> sending it here.

Yes. Exactly the right thing, thanks.

I have applied the patch and pushed it out into .git.  It will appear
in the next release of mdadm.

Thank,
NeilBrown

> 
> I have a small patch to mdamd which allows the write-behind amount to be
> set a array grow time (instead of currently only at grow or create
> time). I have tested this fairly extensively on some arrays built out of
> loop back devices, and once on a real live array. I haven't lot any data
> and it seems to work OK, though it is possible I am missing something.
> 
> --- mdadm-2.6.1/mdadm.c.writebehind	2006-12-21 16:12:50.000000000 +1030
> +++ mdadm-2.6.1/mdadm.c	2007-06-30 13:16:22.000000000 +0930
> @@ -827,6 +827,7 @@
>  			bitmap_chunk = bitmap_chunk ? bitmap_chunk * 1024 : 512;
>  			continue;
>  
> +		case O(GROW, WriteBehind):
>  		case O(BUILD, WriteBehind):
>  		case O(CREATE, WriteBehind): /* write-behind mode */
>  			write_behind = DEFAULT_MAX_WRITE_BEHIND;
> 
> 
> -- 
> Ian Dall <ian@beware.dropbear.id.au>