Mike Tran writes:
I tried the patch and immediately found problems.
On creation of raid1 array, only the spare has md superblock, the raid
disks has no superblock. For instance:
mdadm -C /dev/md0 -l 1 -n 2 /dev/hdd1 /dev/hdd2 -x 1 /dev/hdd3
[wait for resync to finish if you want to...]
mdadm -
I tried the patch and immediately found problems.
On creation of raid1 array, only the spare has md superblock, the raid
disks has no superblock. For instance:
mdadm -C /dev/md0 -l 1 -n 2 /dev/hdd1 /dev/hdd2 -x 1 /dev/hdd3
[wait for resync to finish if you want to...]
mdadm --stop /dev/md0
mdadm
Mike Tran writes:
Hi Peter,
After applying this patch, have you tried stop and restart the MD
array? I believe the spares will be kicked out in analyze_sbs()
function (see the second ITERATE_RDEV)
mdadm ( v1.6.0 - 4 June 2004 )
shows the arrays complete including spare.
/proc/mdstat is ok
I
Hi Peter,
After applying this patch, have you tried stop and restart the MD
array? I believe the spares will be kicked out in analyze_sbs()
function (see the second ITERATE_RDEV)
--
Regards,
Mike T.
On Wed, 2005-03-09 at 09:53, Peter Evertz wrote:
> This patch removes my problem. I hope it doe
This patch removes my problem. I hope it doesn't have influence on the
stability of
the system.
It is simple: The Update routine skips normaly only "faulty" disks. Now it
skips all disk
that are not part of the working array ( raid_disk == -1 )
I made some testing, but surely not all, so :
DON'
On 08.03.2005 14:13, Gordon Henderson wrote:
On Tue, 8 Mar 2005, Tobias Hofmann wrote:
[...]
I had found postings on the net claiming that doing so without
unmounting the fs on the raid, this would lead to bad things happening -
but your report seems to prove them wrong...
I've been using somethi
Gordon Henderson wrote:
I'm in the middle of building up a new home server - looking at RAID-5 or
6 and 2.6.x, so maybe it's time to look at all this again, but it sounds
like the auto superblock update might thwart it all now...
Nah... As far as I can tell, 20ms after the last write, the auto supe
Neil Brown wrote:
On Monday March 7, [EMAIL PROTECTED] wrote:
I have no idea, but...
Is the disk IO reads or writes. If writes, scary Maybe data destined
for the array goes to the spare sometimes. I hope not. I feel safe with my
2.4 kernel. :)
It is writes, but don't be scared. It
On Tue, 8 Mar 2005, Tobias Hofmann wrote:
> > I stuffed a bunch of cheap SATA disks and crappy controllers in an old
> > system. (And replaced the power supply with one that has enough power
> > on the 12V rail.)
> >
> > It's running 2.4, and since it's IDE disks, I just call 'hdparm
> > -S' in rc
On 08.03.2005 09:57, Molle Bestefich wrote:
[...]
I'm gonna CC the list anyway, hope it's okay :-).
I hope so, too... ;)
[...]
No, but I can tell you what I did.
I stuffed a bunch of cheap SATA disks and crappy controllers in an old system.
(And replaced the power supply with one that has enough po
Tobias wrote:
[...]
> I just found your mail on this list, where I have been lurking for
> some weeks now to get acquainted with RAID, but I fear my mail would
> be almost OT there:
Think so? It's about RAID on Linux isn't it?
I'm gonna CC the list anyway, hope it's okay :-).
>> I was just curio
Neil Brown wrote:
As the event count needs to be updated every time the superblock is
modified, the event count will be updated forever active->clean or
clean->active transition. All the drives in an array must have the
same value for the event count, so the spares need to be updated even
though t
Neil Brown wrote:
>> Is my perception of the situation correct?
>
> No. Writing the superblock does not cause the array to be marked
> active.
> If the array is idle, the individual drives will be idle.
Ok, thank you for the clarification.
>> Seems like a design flaw to me, but then again, I'm
On Tuesday March 8, [EMAIL PROTECTED] wrote:
> Neil Brown wrote:
> > Then after 20ms with no write, they are all marked 'clean'.
> > Then before the next write they are all marked 'active'.
> >
> > As the event count needs to be updated every time the superblock is
> > modified, the event count wi
Neil Brown wrote:
> Then after 20ms with no write, they are all marked 'clean'.
> Then before the next write they are all marked 'active'.
>
> As the event count needs to be updated every time the superblock is
> modified, the event count will be updated forever active->clean or
> clean->active tr
On Tuesday March 8, [EMAIL PROTECTED] wrote:
> Neil Brown wrote:
> > It is writes, but don't be scared. It is just super-block updates.
> >
> > In 2.6, the superblock is marked 'clean' whenever there is a period of
> > about 20ms of no write activity. This increases the chance on a
> > resync wo
Neil Brown wrote:
> It is writes, but don't be scared. It is just super-block updates.
>
> In 2.6, the superblock is marked 'clean' whenever there is a period of
> about 20ms of no write activity. This increases the chance on a
> resync won't be needed after a crash.
> (unfortunately) the superb
: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Peter Evertz
> Sent: Monday, March 07, 2005 11:05 PM
> To: linux-raid@vger.kernel.org
> Subject: Spare disk could not sleep / standby
>
> I have 2 Raid5 arrays on a hpt375. Each has a (unused) spare disk.
> W
Evertz
Sent: Monday, March 07, 2005 11:05 PM
To: linux-raid@vger.kernel.org
Subject: Spare disk could not sleep / standby
I have 2 Raid5 arrays on a hpt375. Each has a (unused) spare disk.
With change from 2.4 to 2.6 I can not put the spare disk to sleep or
standby.
It wakes up after some seconds
I have 2 Raid5 arrays on a hpt375. Each has a (unused) spare disk.
With change from 2.4 to 2.6 I can not put the spare disk to sleep or
standby.
It wakes up after some seconds.
/proc/diskstat shows activities every 2 to 5 seconds.
It is a problem of the plain kernel driver ( not application
20 matches
Mail list logo
