-stable review patch. If anyone has any objections, please let us know.
--
From: NeilBrown <[EMAIL PROTECTED]>
If save_raid_disk is >= 0, then the device could be a device that is
already in sync that is being re-added. So we need to default this
value to -1.
Signed-off-by: N
-stable review patch. If anyone has any objections, please let us know.
--
From: NeilBrown <[EMAIL PROTECTED]>
Two less-used md personalities have bugs in the calculation of
->degraded (the extent to which the array is degraded).
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
S
Hi,
On Tue, Oct 31, 2006 at 08:50:19AM -0800, Mike Hardy wrote:
> >> 1 "Warm swap" - replacing drives without taking down the array but maybe
> >> having to type in a few commands. Presumably a sata or sata/raid
> >> interface issue. (True hot swap is nice but not worth delaying warm-
> >> swap.)
Hi,
On Tue, Oct 31, 2006 at 08:50:19AM -0800, Mike Hardy wrote:
> >> 1 "Warm swap" - replacing drives without taking down the array but maybe
> >> having to type in a few commands. Presumably a sata or sata/raid
> >> interface issue. (True hot swap is nice but not worth delaying warm-
> >> swap.)
On Tue, Oct 31, 2006 at 05:00:40PM +1100, NeilBrown wrote:
> Following are 6 patches for md in -lastest which I have been sitting
> on for a while because I hadn't had a chance to test them properly.
> I now have so there shouldn't be too many bugs left :-)
>
> First is suitable for 2.6.19 (if it
On Tue, Oct 31, 2006 at 05:00:46PM +1100, NeilBrown wrote:
>
> This allows udev to do something intelligent when an
> array becomes available.
>
> cc: [EMAIL PROTECTED]
> Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
Acked-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
-
To unsubscribe from this lis
On Oct 26, 7:25am, Neil Brown wrote:
} Subject: Re: RAID5 refuses to accept replacement drive.
Hi Neil, hope your week is going well, thanks for the reply.
> > Environment:
> > Kernel: 2.4.33.3
> > MDADM: 2.4.1/2.5.3
> > MD: Three drive RAID5 (md3)
> Old kernel, new mdadm. Not
John Rowe wrote:
All this discussion has led me to wonder if we users of linux RAID have
a clear consensus of what our priorities are, ie what are the things we
really want to see soon as opposed to the many things that would be nice
but not worth delaying the important things for. FWIW, here ar
Neil Brown wrote:
> On Tuesday October 31, [EMAIL PROTECTED] wrote:
>> 1 "Warm swap" - replacing drives without taking down the array but maybe
>> having to type in a few commands. Presumably a sata or sata/raid
>> interface issue. (True hot swap is nice but not worth delaying warm-
>> swap.)
>
> I have been using an older 64bit system, socket 754 for a while now. It
> has
> the old PCI bus 33Mhz. I have two low cost (no HW RAID) PCI SATA I cards
> each with 4 ports to give me an eight disk RAID 6. I also have a Gig NIC,
> on the PCI bus. I have Gig switches with clients connecting to
Thanks for this Neil, good to know that most of what I would like is
already available. I think your reply highlights what I almost put in
there as my first priority: documentation, specifically a HOWTO.
> I believe that 2.6.18 has SATA hot-swap, so this should be available
> know ... providing yo
On Tuesday October 31, [EMAIL PROTECTED] wrote:
> All this discussion has led me to wonder if we users of linux RAID have
> a clear consensus of what our priorities are, ie what are the things we
> really want to see soon as opposed to the many things that would be nice
> but not worth delaying the
All this discussion has led me to wonder if we users of linux RAID have
a clear consensus of what our priorities are, ie what are the things we
really want to see soon as opposed to the many things that would be nice
but not worth delaying the important things for. FWIW, here are mine, in
order alt
* Jens Axboe ([EMAIL PROTECTED]) wrote:
> On Tue, Oct 31 2006, NeilBrown wrote:
> > This would be good for 2.6.19 and even 18.2, if it is seens acceptable.
> > raid0 at least (possibly other) can be made to Oops with a bad partition
> > table and best fix seem to be to not let out-of-range request
On Tue, Oct 31 2006, Neil Brown wrote:
> On Tuesday October 31, [EMAIL PROTECTED] wrote:
> > On Tue, Oct 31 2006, Neil Brown wrote:
> > >
> > > I'm guessing we need
> > >
> > > diff .prev/block/elevator.c ./block/elevator.c
> > > --- .prev/block/elevator.c2006-10-31 20:06:22.0 +11
On Tuesday October 31, [EMAIL PROTECTED] wrote:
> On Tue, Oct 31 2006, Neil Brown wrote:
> >
> > I'm guessing we need
> >
> > diff .prev/block/elevator.c ./block/elevator.c
> > --- .prev/block/elevator.c 2006-10-31 20:06:22.0 +1100
> > +++ ./block/elevator.c 2006-10-31 20:06:40.
On Tue, Oct 31 2006, Neil Brown wrote:
> On Tuesday October 31, [EMAIL PROTECTED] wrote:
> > On Tue, 31 Oct 2006 17:00:51 +1100
> > NeilBrown <[EMAIL PROTECTED]> wrote:
> >
> > > Currently md devices are created when first opened and remain in existence
> > > until the module is unloaded.
> > > Th
On Tuesday October 31, [EMAIL PROTECTED] wrote:
> On Tue, 31 Oct 2006 17:00:51 +1100
> NeilBrown <[EMAIL PROTECTED]> wrote:
>
> > Currently md devices are created when first opened and remain in existence
> > until the module is unloaded.
> > This isn't a major problem, but it somewhat ugly.
> >
On Tue, 31 Oct 2006 17:00:51 +1100
NeilBrown <[EMAIL PROTECTED]> wrote:
> Currently md devices are created when first opened and remain in existence
> until the module is unloaded.
> This isn't a major problem, but it somewhat ugly.
>
> This patch changes the lifetime rules so that an md device w
19 matches
Mail list logo
