<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
George Mari wrote:
<blockquote cite="mid:494A5617.8010104@mari1938.org" type="cite">
  <pre wrap="">
For me, it would have been much more time to "format the lot and start 
over", and restore from my backup, than it would to just take a little 
time to do some research on how to recover.
  </pre>
</blockquote>
If it was a data drive with important stuff on it then yeah i can see
spending time on it.<br>
Alternately if its just TV... ;-&gt;<br>
<blockquote cite="mid:494A5617.8010104@mari1938.org" type="cite">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <pre wrap="">IE the array is in an inconsistent state and theres no real way to 
reconcile that.

    </pre>
  </blockquote>
  <pre wrap=""><!---->
With one drive dead and another drive with a different value for 
'events' like Mark has, you can force assemble the array with one 
missing drive, fsck the filesystem to make sure it's ok (JFS has never 
missed a beat for me) and add in a new drive.

Now, granted - in my situations, I knew that the filesystems that were 
on these arrays were not being written to at the time of failure, so 
that made success much more likely.

  </pre>
  <blockquote type="cite">
    <pre wrap="">Only other thought I seem to remember something about needing to pass 
mdadm an option when rebuilding to tell it to make it into a new array 
or some such, might only have been when you moved the array to a 
different host though.

    </pre>
  </blockquote>
  <pre wrap=""><!---->
There is no such option, to the best of my knowledge.  Have you done 
this before?  Even explicitly telling mdadm to create a new array, using 
the same devices/partitions that were in the array before, mdadm will 
basically try to re-create the old array if it sees there was an array 
there before.  That's what one of the links I posted previously explain.
  </pre>
</blockquote>
I recall needing to give mdam some special loving to get it to work
when I moved an array from one machine to another, i seem to recall
vuagley similar errors.<br>
I am wondering if the OP might be facing the same problem.<br>
<blockquote cite="mid:494A5617.8010104@mari1938.org" type="cite">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <pre wrap="">When you sort it all out, use storage groups rather than raid, you will 
get much better performance and probably disk life, the seek load is 
going to be drastically reduced.
_______________________________________________
    </pre>
  </blockquote>
  <pre wrap=""><!---->
To each their own.  I have nothing against storage groups, and haven't 
tried them yet, as RAID5 has been wonderful for me, but that's an 
awfully general statement regarding "much better performance".  Got any 
hard data comparing performance of RAID5 and storage groups?  Yeah, 
yeah, I know - the infamous RAID5 write performance penalty.  Sure, it's 
there - but for mythtv, or for storing large amounts of media files, who 
cares?  Write performance is more than good enough for those use case 
scenarios.
  </pre>
</blockquote>
For me its a few personal experiences.<br>
I have a raid 0 setup (started before storage groups were available)
and if I watch something whilst something else is being recorded and
commflagged the little blue light is almost solid on. I had to add more
ram to the machine to let it record 2 shows and watch a 3rd. I needed
to go to 2gb of ram from 1gb, adding a further 2gb helped some more too.<br>
My fathers myth box which is a P4 3ghz (vs my Q6600) was doing about
the same job (without the commercial flagging, but as that is in
realtime on my machine it shouldn't affect disk IO much at all) will
record 2 shows and watch a 3rd with 512mb of ram and the disk light
flashes at about 1-2 Hz.<br>
<br>
Sure you can tweak things to try and work around the seek time issue
while your on raid but with storage groups so handy just use them. It
seems to let everything run much easier. Worst case a drive failure
takes out some hours of TV, you should have better things to do anyway
;-&gt;<br>
<br>
What I plan to do for the next round is to partition some large drives
up 80/20 for storage groups and raid 5.<br>
put bulk TV on the storage group, then anything "important" gets moved
into the raid 5 storage area.<br>
<br>
</body>
</html>