- Original Message -
From: Neil Brown [EMAIL PROTECTED]
To: JaniD++ [EMAIL PROTECTED]
Cc: linux-raid@vger.kernel.org
Sent: Thursday, December 22, 2005 5:46 AM
Subject: Re: RAID5 resync question BUGREPORT!
On Monday December 19, [EMAIL PROTECTED] wrote:
- Original Message
On Monday December 19, [EMAIL PROTECTED] wrote:
- Original Message -
From: Neil Brown [EMAIL PROTECTED]
To: JaniD++ [EMAIL PROTECTED]
Cc: linux-raid@vger.kernel.org
Sent: Monday, December 19, 2005 1:57 AM
Subject: Re: RAID5 resync question BUGREPORT!
How big is your array
- Original Message -
From: Neil Brown [EMAIL PROTECTED]
To: JaniD++ [EMAIL PROTECTED]
Cc: linux-raid@vger.kernel.org
Sent: Monday, December 19, 2005 1:57 AM
Subject: Re: RAID5 resync question BUGREPORT!
On Thursday November 17, [EMAIL PROTECTED] wrote:
Hello,
Now i trying
resync question
On Tuesday December 6, [EMAIL PROTECTED] wrote:
- Original Message -
From: Neil Brown [EMAIL PROTECTED]
To: JaniD++ [EMAIL PROTECTED]
Cc: linux-raid@vger.kernel.org
Sent: Tuesday, December 06, 2005 1:32 AM
Subject: Re: RAID5 resync question
On Tuesday
On Friday December 9, [EMAIL PROTECTED] wrote:
Hello, Neil,
[EMAIL PROTECTED] mdadm-2.2]# mdadm --grow /dev/md0 --bitmap=internal
mdadm: Warning - bitmaps created on this kernel are not portable
between different architectured. Consider upgrading the Linux kernel.
Dec 8 23:59:45
the bitmap-create and bitmap update.)
My data lost finally, really minimal. :-)
Cheers,
Janos
- Original Message -
From: Neil Brown [EMAIL PROTECTED]
To: JaniD++ [EMAIL PROTECTED]
Cc: linux-raid@vger.kernel.org
Sent: Friday, December 09, 2005 12:43 AM
Subject: Re: RAID5 resync question
On Friday December 9, [EMAIL PROTECTED] wrote:
Hi,
After i get this on one of my disk node, imediately send this letter, and go
to the hosting company, to see, is any message on the screen.
But unfortunately nothing what i found.
simple freeze.
no message, no ping, no num lock!
The full
I know, it is some chance to leave some incorrect parity information on
the
array, but may be corrected by next write.
Or it may not be corrected by the next write. The parity-update
algorithm assumes that the parity is correct.
Hmm.
If it works with parity-update algorithm, instead of
On Tuesday December 6, [EMAIL PROTECTED] wrote:
I know, it is some chance to leave some incorrect parity information on
the
array, but may be corrected by next write.
Or it may not be corrected by the next write. The parity-update
algorithm assumes that the parity is correct.
One time while my array is really rebuild one disk (paralel normal
workload), i see, the new drive in the array *only* writes.
i means with better handling of half-synced array is this:
If read request comes to the ?% synced array, and if the read is on the
synced half, only need to
On Tuesday December 6, [EMAIL PROTECTED] wrote:
Hello, list,
Is there a way to force the raid to skip this type of resync?
Why would you want to?
The array is 'unclean', presumably due to a system crash. The parity
isn't certain to be correct so your data isn't safe against a device
On Tuesday December 6, [EMAIL PROTECTED] wrote:
- Original Message -
From: Neil Brown [EMAIL PROTECTED]
To: JaniD++ [EMAIL PROTECTED]
Cc: linux-raid@vger.kernel.org
Sent: Tuesday, December 06, 2005 1:32 AM
Subject: Re: RAID5 resync question
On Tuesday December 6, [EMAIL
12 matches
Mail list logo
