headers
Ask Bjørn Hansen | 3 Jan 2007 07:46
Gravatar

raid10_make_request bug: can't convert block across chunks or bigger [...]

Hi,

I have a logical volume I'm (trying to) use for a Xen box.   When  
it's installing the boot loader I get a bunch of errors like the ones  
below.  The kernel is the latest FC6 kernel - 2.6.18-1.2869.fc6xen.

The md device is a raid10 device (obviously) across 4 sata disks.

  Any ideas?

[....]
raid10_make_request bug: can't convert block across chunks or bigger  
than 64k 81830779 4
raid10_make_request bug: can't convert block across chunks or bigger  
than 64k 81847167 4
raid10_make_request bug: can't convert block across chunks or bigger  
than 64k 81879931 4
raid10_make_request bug: can't convert block across chunks or bigger  
than 64k 81896315 4
[...]

  - ask

--

-- 
http://develooper.com/ - http://askask.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Merillat | 3 Jan 2007 07:48
Picon

md: bug in file drivers/md/md.c, line 1662

Jan  3 01:24:12 chaos kernel: [  830.038426] md: bug in file
drivers/md/md.c, line 1662
Jan  3 01:24:12 chaos kernel: [  830.038524]
Jan  3 01:24:12 chaos kernel: [  830.038608]
md:^I**********************************
Jan  3 01:24:12 chaos kernel: [  830.038697] md:^I* <COMPLETE RAID
STATE PRINTOUT> *
Jan  3 01:24:12 chaos kernel: [  830.038787]
md:^I**********************************
Jan  3 01:24:12 chaos kernel: [  830.038879] md0: <sdd2><sdc2><sdb2><sda2>
Jan  3 01:24:12 chaos kernel: [  830.039116] md: rdev sdd2,
SZ:219777152 F:0 S:1 DN:3
Jan  3 01:24:12 chaos kernel: [  830.039206] md: rdev superblock:
Jan  3 01:24:12 chaos kernel: [  830.039297] md:  SB: (V:1.0.0)
ID:<ad8e8baf.00000000.00000000.00000
000> CT:06707edf
Jan  3 01:24:12 chaos kernel: [  830.039448] md:     L-496822052
S00000048 ND:0 RD:0 md0 LO:65536 CS
:196610
Jan  3 01:24:12 chaos kernel: [  830.039547] md:     UT:00000000 ST:0
AD:439554320 WD:0 FD:439554448
 SD:0 CSUM:00000000 E:00000000
Jan  3 01:24:12 chaos kernel: [  830.039700]      D  0:
DISK<N:-1,(-1,-1),R:-1,S:-1>
Jan  3 01:24:12 chaos kernel: [  830.039851]      D  1:
DISK<N:-1,(-1,-1),R:-1,S:-1>
Jan  3 01:24:12 chaos kernel: [  830.039971]      D  2:
DISK<N:-1,(-1,-1),R:-1,S:-1>
Jan  3 01:24:12 chaos kernel: [  830.040093]      D  3:
DISK<N:-1,(-1,-1),R:-1,S:-1>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vince Spinelli | 5 Jan 2007 07:23

mdadm: what if - crashed OS

Hello,

My name is Vince Spinelli, from Buffalo, NY (US).  I am currently using
'mdadm' under Fedora Core 5 (32-bit) to run two Soft-RAID arrays.

1) RAID-1 (mirror) for mission critical data.  #drives = 2 ea. PATA ATA100
2) RAID-5 (striped+parity) for multimedia data.  #drives = 5 ea. SATA 3G

My question is this...

In case of catastropic machine failure, such as the operating system
(which is on a separate PATA ATA100 drive) failing or even the OS hard
drive being physically destroyed, how would I go about rebuilding my RAID
arrays?

Obviously, this would assume that the 7 disks which make up my arrays had
survived and were not damaged.

-I would obviously then build a new computer,
-install Linux, make sure 'mdadm' was installed,
-physically install all of my drives into the computer,
-copy my old /etc/mdadm.conf file (which has been saved on cd-rom but is
easily re-made) onto the new computer,
- and then what?

I have thought about this, and I can't understand how 'mdadm' decides the
health of an array.

For example, if I type at prompt:
(Continue reading)

Permalink | Reply | 4 comments |
headers
liyiming | 5 Jan 2007 09:11
Picon

There is an advice

In the stop function of any level raid device driver such as faulty, multipath, and raidx
It would better set the mddev->private NULL before free the conf structure. 

 
 				
--------------
liyiming
2007-01-05

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Francois Barre | 5 Jan 2007 11:59
Picon

Raid1 : mounting a 1.0-version raid as root at boot time not working

Hi all,

First of all, best wishes for 2007, may the Penguin be with you for
the whole year on.

Then, my problem.

1. The setup : x86_64 2x500GB sata, linux 2.6.18-6, raid 1 on
/dev/sd[ab]1 -> /dev/md0.
Raid1 is configured with a 1.0 superblock version, but no autoraid 0xfd stuff.
The aim is to have / mounted on md0.
Lilo has been teached to have root=/dev/md0 and
md=0,/dev/sda1,/dev/sdb1, and with an explicit "raid=noautodetect".
The rest is not (that) important.

2. The symptoms :
At boot time, we do have the correct md: "Loading md0 :
/dev/sda1,/dev/sdb1" message
but while tryping to add /dev/sda1 in /dev/md0, we have :
"md: /dev/sda1 has invalid sb, not importing!"
Same thing for /dev/sdb1

3. My guess...
I must test this a bit further, but my guess is as follows :
- not being autodetected, /dev/md0 device is created using a 0.9
version by default : in md.c: set_array_info(), as info is memset(),
info->major_version is zero.
- then at md.c: add_new_disk(), md_import_device() is called with
mddev->major_version=0.
- md_import_device() fails because it's told to load a superblock v0.x
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Greaves | 5 Jan 2007 12:21
Favicon
Gravatar

Re: mdadm: what if - crashed OS

Assuming you can allow some downtime, get yourself a rescue CD such as 'RIP'

This will let you boot into the machine and run mdadm commands.

You don't mention kernel/mdadm versions so you may want to check they're close
on the rescue CD.

Then try looking at the manpage around --assemble.
In particular you may want to try --scan and --uuid (if your RIP/live
kernel/mdadm support it)

Also check out the examples...

Assuming this is a sane machine and you're not in real disaster recovery mode
with drives pulled in from random boxes then look at using the literal string
"--config=partitions" (see the manpage) to avoid creating an mdadm.conf with the
"DEVICE partitions" line - PITA on live CDs where you just want a command line ;)

If you can manage it, this will give you a nice warm feeling about recovering
from a problem and it's pretty safe - just common sense like making sure the
live CD kernel/mdadm are either up-to-date or match your production system.

HTH

Also:
> I have thought about this, and I can't understand how 'mdadm' decides the
> health of an array.

Each disk/partition used by md has a superblock which contains a unique UUID and
other info, like the number of devices and the raid level. mdadm --scan looks
(Continue reading)

Permalink | Reply | 1 comment |
headers
Francois Barre | 5 Jan 2007 16:26
Picon

Re: Raid1 : mounting a 1.0-version raid as root at boot time not working

From Documentation/md.txt

"As of kernel 2.6.9, only drives with a type 0 superblock can be
autodetected and run at boot time."

Sorry for the noise, I shall have understood that by myself...

In order to fix this issue, isn't it possible to implement in kernel a
behaviour close to what we can find in util.c: guess_super() of the
mdadm package ?
Would that be too dangerous ?
It seems to me that the tricky part is dealing with the ctime stuff of
all possible superblocks found...

Regards,

2007/1/5, Francois Barre <francois.barre <at> gmail.com>:
> Hi all,
>
> First of all, best wishes for 2007, may the Penguin be with you for
> the whole year on.
>
> Then, my problem.
>
> 1. The setup : x86_64 2x500GB sata, linux 2.6.18-6, raid 1 on
> /dev/sd[ab]1 -> /dev/md0.
> Raid1 is configured with a 1.0 superblock version, but no autoraid 0xfd stuff.
> The aim is to have / mounted on md0.
> Lilo has been teached to have root=/dev/md0 and
> md=0,/dev/sda1,/dev/sdb1, and with an explicit "raid=noautodetect".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Davidsen | 5 Jan 2007 22:51

Re: mdadm: what if - crashed OS

Vince Spinelli wrote:
> Hello,
>
> My name is Vince Spinelli, from Buffalo, NY (US).  I am currently using
> 'mdadm' under Fedora Core 5 (32-bit) to run two Soft-RAID arrays.
>
> 1) RAID-1 (mirror) for mission critical data.  #drives = 2 ea. PATA ATA100
> 2) RAID-5 (striped+parity) for multimedia data.  #drives = 5 ea. SATA 3G
>
> My question is this...
>
> In case of catastropic machine failure, such as the operating system
> (which is on a separate PATA ATA100 drive) failing or even the OS hard
> drive being physically destroyed, how would I go about rebuilding my RAID
> arrays?
>   
May I say that if you don't want to lose your data, then the o/s is 
"critical data." I regard boot, root, and swap as critical, because if 
they fail you have a much more complex recovery issue. Also note that 
you still need backup, because some hardware failure modes will write 
bad data (maybe silently) without an actual "crash" you notice. Power 
supplies, controllers, and disk drives will help you test your backup 
procedures.
> Obviously, this would assume that the 7 disks which make up my arrays had
> survived and were not damaged.
>
> -I would obviously then build a new computer,
> -install Linux, make sure 'mdadm' was installed,
> -physically install all of my drives into the computer,
> -copy my old /etc/mdadm.conf file (which has been saved on cd-rom but is
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Geppert | 5 Jan 2007 23:25

Re: mdadm: what if - crashed OS

This actually happened to me recently where my OS HDD had a complete
physical failure. Unfortunately, I do not have a copy of the config files.
What additional tasks are needed to re-create the config files - or is this
done by -assemble?

AMG
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Vince Spinelli | 6 Jan 2007 05:10

Re: mdadm: what if - crashed OS

Thank you all for the responses and help (you guys are FAST!)...

I have successfully simulated a worst case scenario and 'rebuilt the
arrays from scratch' while preserving all data.

This is how I did it, for anyone who may run into the same jam:

1) removed OS hdd, temporarily installed scrap (read as: old 4 GB IDE HDD)
hard drive.  Installed same version of Linux - FC5, and same kernel.
2) copied (From cd backup) original mdadm.conf to /etc/mdadm.conf
3) as reccomended, executed following at command line...
[abc <at> 123]# /sbin/mdadm --assemble --uuid=[UUIDOFARRAY] --scan /dev/md1
4) rebooted

This resulted in the array popping right up, and being accessible with all
data in tact.

Thank you again for all the help!  I will now be working on a live cd to
suite my taste, so that this all would be a little easier.

FYI --- kernel being used is a prepackaged one from Livna Repository,
2.6.17-1.2187_FC5.stk16 #1 Mon Sep 25 17:32:45 EDT 2006 i686
mdadm version being used is,
mdadm.i386 2.3.1-3

-Regards
Vince

---------------------------------------
Vince Spinelli
(Continue reading)

Permalink | Reply | 0 comments |

Gmane