On Thu, 8 Nov 2007, Carlos Carvalho wrote:
Jeff Lessem ([EMAIL PROTECTED]) wrote on 6 November 2007 22:00:
Dan Williams wrote:
The following patch, also attached, cleans up cases where the code looks
at sh-ops.pending when it should be looking at the consistent
stack-based snapshot of
Richard Scobie said: (by the date of Fri, 09 Nov 2007 10:32:08 +1300)
This was the bug I was thinking of:
http://marc.info/?l=linux-raidm=116003247912732w=2
This bug says that it only with mdadm 1.x:
If a drive is added to a raid1 using older tools
(mdadm-1.x or raidtools) then
Dan Williams wrote:
On 11/8/07, Bill Davidsen [EMAIL PROTECTED] wrote:
Jeff Lessem wrote:
Dan Williams wrote:
The following patch, also attached, cleans up cases where the code
looks
at sh-ops.pending when it should be looking at the consistent
stack-based snapshot of the operations flags.
Thanks David.
I've had cable/port failures in the past and after re-adding the drive,
the order changed - I'm not sure why, but I noticed it sometime ago but
don't remember the exact order.
My initial attempt to assemble, it came up with only two drives in the
array. Then I tried
Hi David,
I ran xfs_check and get this:
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed. Mount the filesystem to replay the log, and unmount it before
re-running xfs_check. If you are unable to mount the filesystem, then use
the xfs_repair -L option to
