David Greaves wrote:
Bill Davidsen wrote:
Leon Woestenberg wrote:
We will try to make disk clones first. Will dd suffice or do I need
something more fancy that maybe copes with source drive read errors in
a better fashion?
Yes to both. dd will be fine in most cases, and I sugge
Hello all,
On 4/26/07, David Greaves <[EMAIL PROTECTED]> wrote:
Bill Davidsen wrote:
> Leon Woestenberg wrote:
>> We will try to make disk clones first. Will dd suffice or do I need
>> something more fancy that maybe copes with source drive read errors in
>> a better fashion?
>
> Yes to both. dd
Bill Davidsen wrote:
> Leon Woestenberg wrote:
>> We will try to make disk clones first. Will dd suffice or do I need
>> something more fancy that maybe copes with source drive read errors in
>> a better fashion?
>
> Yes to both. dd will be fine in most cases, and I suggest using noerror
> to con
On Tuesday April 24, [EMAIL PROTECTED] wrote:
> David,
>
> thanks for all the advice so far.
>
> On 4/24/07, David Greaves <[EMAIL PROTECTED]> wrote:
> >
> > Essentially all --create does is create superblocks with the data you want
> > (eg
> > slot numbers). It does not touch other 'on disk dat
Leon Woestenberg wrote:
In first instance we were searching for ways to tell mdadm what we
know about the array (through mdadm.conf) but from all advice we got
we have to take the 'usual' non-syncing-recreate approach.
We will try to make disk clones first. Will dd suffice or do I need
something
Leon Woestenberg wrote:
> David,
>
> thanks for all the advice so far.
No problem :)
> In first instance we were searching for ways to tell mdadm what we
> know about the array (through mdadm.conf) but from all advice we got
> we have to take the 'usual' non-syncing-recreate approach.
>
> We wi
David,
thanks for all the advice so far.
On 4/24/07, David Greaves <[EMAIL PROTECTED]> wrote:
Leon Woestenberg wrote:
> On 4/24/07, Leon Woestenberg <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> On 4/23/07, David Greaves <[EMAIL PROTECTED]> wrote:
>> > There is some odd stuff in there:
>> >
>> [EM
Leon Woestenberg wrote:
> On 4/24/07, Leon Woestenberg <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> On 4/23/07, David Greaves <[EMAIL PROTECTED]> wrote:
>> > There is some odd stuff in there:
>> >
>> [EMAIL PROTECTED] ~]# mdadm -v --assemble --scan
>> --config=/tmp/mdadm.conf --force
>> [...]
>> mdad
On 4/24/07, Leon Woestenberg <[EMAIL PROTECTED]> wrote:
Hello,
On 4/23/07, David Greaves <[EMAIL PROTECTED]> wrote:
> There is some odd stuff in there:
>
[EMAIL PROTECTED] ~]# mdadm -v --assemble --scan --config=/tmp/mdadm.conf
--force
[...]
mdadm: no uptodate device for slot 1 of /dev/md0
mdad
Hello,
On 4/23/07, David Greaves <[EMAIL PROTECTED]> wrote:
There is some odd stuff in there:
/dev/sda1:
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Events : 0.115909229
/dev/sdb1:
Active Devices : 5
Working Devices : 4
Failed Devices : 1
Events : 0.115909230
/dev/sdc1:
Active D
There is some odd stuff in there:
/dev/sda1:
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Events : 0.115909229
/dev/sdb1:
Active Devices : 5
Working Devices : 4
Failed Devices : 1
Events : 0.115909230
/dev/sdc1:
Active Devices : 8
Working Devices : 8
Failed Devices : 1
Events : 0.11
Hello,
it's recovery time again. Problem at hand: raid5 consisting of four
partitions, each on a drive. Two disks have failed. Assembly fails
because the slot numbers of the array components seem to be corrupt.
/dev/md0 consisting of /dev/sd[abcd]1, of which b,c failed and of
which c seems reall
12 matches
Mail list logo