Re: [PATCH md 000 of 8] Introduction

Re: [PATCH md 000 of 8] Introduction

[George Iosif]

Hello Neil,

If JimL doesn't want/have the time/etc. to do the patch testing I'd be
willing to do that.
Also, if there is something else I could contribute to, I'll be happy to
do it, given I have time for it (I'm employed so I'll try to do it in my
spare time).

Yours,

George Iosif

>>> Neil Brown <neilb@suse.de> 10/17/05 4:38 AM >>>
On Sunday October 16, babydr@baby-dragons.com wrote:
>  	Hello Neil ,  Is it possible to inert in the 'Introduction's for
your
>  	patches a Min & Max kernel level they will successfully patch
>  	against ?  ie: 2.6.12 to 2.6.14-rc4 or some such .
>  	That would sure take the angst out of guessing .  Tia ,  JimL
> 

I could certainly be more precise about which kernel they are created
against (it is usually the latest 2.6-mm) but it would be a lot of
work to figure out how far back you can safely go and still have the
patch usefully apply, and I'm not sure that it is really worth it, is
it?

If you want to help test raid patch (and I do appreciate the help), it
is really best if you use the most recent kernel, otherwise there
could be unexpected interactions which invalidate the test.

Hope that's ok,

Thanks,
NeilBrown
-
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

[PATCH md 000 of 8] Introduction

[NeilBrown]

8 patches for md/raid in 2.6 follow.

The first replaces 
   md-identify-raid-rcu-protected-pointer.patch
which has some minor issues.
2 and 3 fix problems in previous patches identified by some kindly code reviewers.

Thanks,
NeilBrown


 [PATCH md 001 of 8] Provide proper rcu_dereference / rcu_assign_pointer annotations in md
 [PATCH md 002 of 8] Fix ref-counting problems with kobjects in md
 [PATCH md 003 of 8] Minor MD fixes
 [PATCH md 004 of 8] Change raid5 sysfs attribute to not create a new directory.
 [PATCH md 005 of 8] Improvements to raid5 handling of read errors
 [PATCH md 006 of 8] Convert 'faulty' and 'in_sync' fields to bits in 'flags' field.
 [PATCH md 007 of 8] Make md on-disk bitmaps not host-endian
 [PATCH md 008 of 8] Support BIO_RW_BARRIER for md/raid1.

Re: [PATCH md 000 of 8] Introduction

[Mr. James W. Laferriere]

 	Hello Neil ,  Is it possible to inert in the 'Introduction's for your
 	patches a Min & Max kernel level they will successfully patch
 	against ?  ie: 2.6.12 to 2.6.14-rc4 or some such .
 	That would sure take the angst out of guessing .  Tia ,  JimL

On Fri, 14 Oct 2005, NeilBrown wrote:
> 8 patches for md/raid in 2.6 follow.
>
> The first replaces
>   md-identify-raid-rcu-protected-pointer.patch
> which has some minor issues.
> 2 and 3 fix problems in previous patches identified by some kindly code reviewers.
>
> Thanks,
> NeilBrown
>
>
> [PATCH md 001 of 8] Provide proper rcu_dereference / rcu_assign_pointer annotations in md
> [PATCH md 002 of 8] Fix ref-counting problems with kobjects in md
> [PATCH md 003 of 8] Minor MD fixes
> [PATCH md 004 of 8] Change raid5 sysfs attribute to not create a new directory.
> [PATCH md 005 of 8] Improvements to raid5 handling of read errors
> [PATCH md 006 of 8] Convert 'faulty' and 'in_sync' fields to bits in 'flags' field.
> [PATCH md 007 of 8] Make md on-disk bitmaps not host-endian
> [PATCH md 008 of 8] Support BIO_RW_BARRIER for md/raid1.
> -
> 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
>

-- 
+------------------------------------------------------------------+
| James   W.   Laferriere | System    Techniques | Give me VMS     |
| Network        Engineer | 3542 Broken Yoke Dr. |  Give me Linux  |
| babydr@baby-dragons.com | Billings , MT. 59105 |   only  on  AXP |
+------------------------------------------------------------------+

Re: [PATCH md 000 of 8] Introduction

[Neil Brown]

On Sunday October 16, babydr@baby-dragons.com wrote:
>  	Hello Neil ,  Is it possible to inert in the 'Introduction's for your
>  	patches a Min & Max kernel level they will successfully patch
>  	against ?  ie: 2.6.12 to 2.6.14-rc4 or some such .
>  	That would sure take the angst out of guessing .  Tia ,  JimL
> 

I could certainly be more precise about which kernel they are created
against (it is usually the latest 2.6-mm) but it would be a lot of
work to figure out how far back you can safely go and still have the
patch usefully apply, and I'm not sure that it is really worth it, is
it?

If you want to help test raid patch (and I do appreciate the help), it
is really best if you use the most recent kernel, otherwise there
could be unexpected interactions which invalidate the test.

Hope that's ok,

Thanks,
NeilBrown

Re: [PATCH md 000 of 8] Introduction

[Mr. James W. Laferriere]

 	Hello Neil ,

On Mon, 17 Oct 2005, Neil Brown wrote:
> On Sunday October 16, babydr@baby-dragons.com wrote:
>>  	Hello Neil ,  Is it possible to inert in the 'Introduction's for your
>>  	patches a Min & Max kernel level they will successfully patch
>>  	against ?  ie: 2.6.12 to 2.6.14-rc4 or some such .
>>  	That would sure take the angst out of guessing .  Tia ,  JimL

> I could certainly be more precise about which kernel they are created
> against (it is usually the latest 2.6-mm) .
 	Perfect .  Would you please insert the full kernel source version
 	number the patches were created from in with the 'Introductions' ,
 	Please ?

> but it would be a lot of
> work to figure out how far back you can safely go and still have the
> patch usefully apply, and I'm not sure that it is really worth it, is
> it?
 	Not really what I was looking for .  Was thinking more on the lines of
 	the last kernel version that had accepted a previous patch set of
 	yours as a approximation of patch'ability .  That sound do able ?

> If you want to help test raid patch (and I do appreciate the help), it
> is really best if you use the most recent kernel, otherwise there
> could be unexpected interactions which invalidate the test.
 	I am definately willing to test patch sets .  Whether I'll be able to
 	do so for very long is another matter .  Tnx ,  JimL
-- 
+------------------------------------------------------------------+
| James   W.   Laferriere | System    Techniques | Give me VMS     |
| Network        Engineer | 3542 Broken Yoke Dr. |  Give me Linux  |
| babydr@baby-dragons.com | Billings , MT. 59105 |   only  on  AXP |
+------------------------------------------------------------------+

[PATCH md 000 of 8] Introduction

[NeilBrown]

Following are 8 patches for md in 2.6.13-rc6-mm1.

The first patch could usefully go into 2.6.13.  The remainder should wait
for 2.6.14-rc1.

Number 001 simply calls md_wakeup_thread during raid startup to make
sure that resync gets started.  It is always perfectly safe to call
this function -- as long as we don't call it continuously -- as an
extra wakeup doesn't hurt.
The remainder fix:
    bugs in code that is only in -mm as yet, 
    minor bugs in recently added 'bitmap' code,
    fix a long standing shortcoming with 'linear' the only one person has 
      complained about.

Thanks,
NeilBrown


 [PATCH md 001 of 8] Make sure resync gets started when array starts.
 [PATCH md 002 of 8] Support md/linear array with components greater than 2 terabytes.
 [PATCH md 003 of 8] raid1_quiesce is back to front, fix it.
 [PATCH md 004 of 8] Make sure bitmap_daemon_work actually does work.
 [PATCH md 005 of 8] Do not set mddev->bitmap until bitmap is fully initialised
 [PATCH md 006 of 8] Allow hot-adding devices to arrays with non-persistant superblocks.
 [PATCH md 007 of 8] Allow md to load a superblock with feature-bit '1' set
 [PATCH md 008 of 8] Fix bitmap/read_sb_page so that it handles errors properly.