Linux MD RAID5/6 bitmap patches

Linux MD RAID5/6 bitmap patches

[Yogesh Pahilwan]

Hello,

I want to know where I can get various MD RAID5/RAID6 bitmap patches for
linux kernel 2.6.15.
I want to know what kind of performance optimization possible on bitmap
patches. I also want to know are 
there any patches available which provides performance optimizations using
bitmaps. 

Thanks and Regards
Yogesh

Linux MD RAID5/6 bitmap patches

[Yogesh Pahilwan]

Hello,

I want to know where I can get various MD RAID5/RAID6 bitmap patches for
linux kernel 2.6.15.
I want to know what kind of performance optimization possible on bitmap
patches. I also want to know are there any patches available which provides
performance optimizations using bitmaps. 

Thanks and Regards
Yogesh

Re: Linux MD RAID5/6 bitmap patches

[Neil Brown]

On Wednesday March 22, pahilwan.yogesh@spsoftindia.com wrote:
> Hello,
> 
> I want to know where I can get various MD RAID5/RAID6 bitmap patches for
> linux kernel 2.6.15.

2.6.15 already includes support for bitmaps for MD raid5 and raid6
(And raid1).  No patches needed.

> I want to know what kind of performance optimization possible on bitmap
> patches. I also want to know are 
> there any patches available which provides performance optimizations using
> bitmaps. 

Bitmaps optimise rebuild time after a crash, or after removing and
re-adding a device.  They do not improve normal read/write
performance, and may well cause a small degradation in performance.

NeilBrown

RE: Linux MD RAID5/6 bitmap patches

[Yogesh Pahilwan]

Hi Neil,

Thanks for your reply. As far as what I understood that when we apply the
bitmap patch, for every write it will do 2 sync writes that is setting the
dirty bit, writing intent log and one async write for clearing the dirty
bit. Is it correct?
If that is the case are there any patches available which can do collection
of sync write in a queue and write a collection in single write request.
For Eg:
For 10 writes , we will have 10 + 1 sync writes + 10 async write.
I mean to say , 10 sync writes for setting the dirty bits + 1 sync write for
write intent log for all queued request in one write operation + 10 async
write for clearing the dirty bit.

So as we reducing the sync write request by using collections will it
improve the performance and any patches available which follows this
approach.

Thanks and Regards
Yogesh

-----Original Message-----
From: Neil Brown [mailto:neilb@suse.de] 
Sent: Wednesday, March 22, 2006 3:36 PM
To: Yogesh Pahilwan
Cc: linux-raid@vger.kernel.org
Subject: Re: Linux MD RAID5/6 bitmap patches

On Wednesday March 22, pahilwan.yogesh@spsoftindia.com wrote:
> Hello,
> 
> I want to know where I can get various MD RAID5/RAID6 bitmap patches for
> linux kernel 2.6.15.

2.6.15 already includes support for bitmaps for MD raid5 and raid6
(And raid1).  No patches needed.

> I want to know what kind of performance optimization possible on bitmap
> patches. I also want to know are 
> there any patches available which provides performance optimizations using
> bitmaps. 

Bitmaps optimise rebuild time after a crash, or after removing and
re-adding a device.  They do not improve normal read/write
performance, and may well cause a small degradation in performance.

NeilBrown

Re: Linux MD RAID5/6 bitmap patches

[Paul Clements]

Yogesh Pahilwan wrote:

> Thanks for your reply. As far as what I understood that when we apply the
> bitmap patch, for every write it will do 2 sync writes that is setting the
> dirty bit, writing intent log and one async write for clearing the dirty
> bit. Is it correct?

The bits are in the intent log, so the "setting dirty bit" and "writing 
intent log" are the same thing. Just one write.

> If that is the case are there any patches available which can do collection
> of sync write in a queue and write a collection in single write request.
> For Eg:
> For 10 writes , we will have 10 + 1 sync writes + 10 async write.

The bitmap code already does this by default. The bitmap writes are 
queued up so that all writes to a given page (within a short time 
period) are reduced to a single write. The performance is actually quite 
good. There's very little performance difference between having a bitmap 
versus not having one.

> I mean to say , 10 sync writes for setting the dirty bits + 1 sync write for
> write intent log for all queued request in one write operation + 10 async
> write for clearing the dirty bit.

The async writes for clearing the bitmap are also combined.

--
Paul

RE: Linux MD RAID5/6 bitmap patches

[Yogesh Pahilwan]

Hi Paul,

Thanks for your reply.

Where can we get documentation (design/implementation) about RAID6 and
bitmap for linux kernel 2.6.

Thanks and Regards
Yogesh

-----Original Message-----
From: Paul Clements [mailto:paul.clements@steeleye.com] 
Sent: Wednesday, March 22, 2006 11:37 PM
To: Yogesh Pahilwan
Cc: 'Neil Brown'; linux-raid@vger.kernel.org
Subject: Re: Linux MD RAID5/6 bitmap patches

Yogesh Pahilwan wrote:

> Thanks for your reply. As far as what I understood that when we apply the
> bitmap patch, for every write it will do 2 sync writes that is setting the
> dirty bit, writing intent log and one async write for clearing the dirty
> bit. Is it correct?

The bits are in the intent log, so the "setting dirty bit" and "writing 
intent log" are the same thing. Just one write.

> If that is the case are there any patches available which can do
collection
> of sync write in a queue and write a collection in single write request.
> For Eg:
> For 10 writes , we will have 10 + 1 sync writes + 10 async write.

The bitmap code already does this by default. The bitmap writes are 
queued up so that all writes to a given page (within a short time 
period) are reduced to a single write. The performance is actually quite 
good. There's very little performance difference between having a bitmap 
versus not having one.

> I mean to say , 10 sync writes for setting the dirty bits + 1 sync write
for
> write intent log for all queued request in one write operation + 10 async
> write for clearing the dirty bit.

The async writes for clearing the bitmap are also combined.

--
Paul

Re: Linux MD RAID5/6 bitmap patches

[Paul Clements]

Yogesh Pahilwan wrote:

> Where can we get documentation (design/implementation) about RAID6 and
> bitmap for linux kernel 2.6.

For the bitmap code, I'm afraid you'll just have to read the code. Also, 
look back at the archives of this list. There are several discussions 
about the bitmap patches, going back to 2003.

--
Paul


> -----Original Message-----
> From: Paul Clements [mailto:paul.clements@steeleye.com] 
> Sent: Wednesday, March 22, 2006 11:37 PM
> To: Yogesh Pahilwan
> Cc: 'Neil Brown'; linux-raid@vger.kernel.org
> Subject: Re: Linux MD RAID5/6 bitmap patches
> 
> Yogesh Pahilwan wrote:
> 
> 
>>Thanks for your reply. As far as what I understood that when we apply the
>>bitmap patch, for every write it will do 2 sync writes that is setting the
>>dirty bit, writing intent log and one async write for clearing the dirty
>>bit. Is it correct?
> 
> 
> The bits are in the intent log, so the "setting dirty bit" and "writing 
> intent log" are the same thing. Just one write.
> 
> 
>>If that is the case are there any patches available which can do
> 
> collection
> 
>>of sync write in a queue and write a collection in single write request.
>>For Eg:
>>For 10 writes , we will have 10 + 1 sync writes + 10 async write.
> 
> 
> The bitmap code already does this by default. The bitmap writes are 
> queued up so that all writes to a given page (within a short time 
> period) are reduced to a single write. The performance is actually quite 
> good. There's very little performance difference between having a bitmap 
> versus not having one.
> 
> 
>>I mean to say , 10 sync writes for setting the dirty bits + 1 sync write
> 
> for
> 
>>write intent log for all queued request in one write operation + 10 async
>>write for clearing the dirty bit.
> 
> 
> The async writes for clearing the bitmap are also combined.
> 
> --
> Paul
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>