Re: hard drives with "variable" device names - mdadm raid assembly options setup

Max Waterman <davidmaxwaterman+gmane <at> fastmail.co.uk> writes:
> Daniel Pittman wrote:
>> Mitchell Laks <mlaks <at> verizon.net> writes:

[...]

>> Then, list your arrays:
>> ARRAY /dev/md2 level=raid1 num-devices=2
>> UUID=529d70fa:e5fe992b:ceb05593:bfcc6c25
>> That will cause mdadm to scan all those device entries (all the disks
>> and partitions) looking for an array with the right UUID, and assemble
>> it from all the components it finds.
>
> I am trying to do this with my 8 (currently only 7 since /dev/hdk is off
> line being replaced) disk raid5 array. mdadm --detail /dev/md0 gives :

[...]

>            UUID : 15bfec75:595ac793:0914f8ee:862effd8

[...]

> I am confused why there are only 4 UUIDs, when there are 7 devices
> listed...what should I put in my mdadm.conf file, which is currently 

You surely are confused, but there is only *one* UUID there, not four.

The UUID is presented as four blocks, with a ':' between them, by mdadm
for some reason beyond my understanding, but it is really just one
string.

2.6.15-rc5-mm3 sata_mv raid5 array failure to start

Hello all,

I am still persisting with my quest for a usable sata_mv driver.

The 2.5.15-rc5-m3 kernel appear to have been good to me.

Before I attempt moving to later releases of the 2.6.15 tree I thought 
I'd get feedback from the people in the know

This is an intentional cross-post as I'm not %100 sure if the problems 
sits in the raid error or the actual libata/driver area (more probable)

I have 7 SATA disks hanging of an 8 port controller which uses the 
sata_mv driver.

I create a raid 5 array consisting of 6 disks (using 1 full disk 
partition) and 1 spare

The array builds fine - although it takes 300 minutes so its not a quick 
process to run through tests.

md6 : active raid5 sdh[5] sdi[6](S) sdg[4] sdf[3] sde[2] sdd[1] sdc[0]
      1225586560 blocks level 5, 64k chunk, algorithm 2 [6/6] [UUUUUU]

as you can see, all looking good. sdi is marked as the spare./dev/md6:
        Version : 00.90.03
  Creation Time : Sat Dec 31 16:23:11 2005
     Raid Level : raid5
     Array Size : 1225586560 (1168.81 GiB 1255.00 GB)
    Device Size : 245117312 (233.76 GiB 251.00 GB)

2.6.15-mm3 sata_mv / raid 5 array start failure on boot

Hello all,

I am still persisting with my quest for a usable sata_mv driver.

The 2.5.15-rc5-m3 kernel appear to have been good to me.

Before I attempt moving to later releases of the 2.6.15 tree I thought 
I'd get feedback from the people in the know

This is an intentional cross-post as I'm not %100 sure if the problems 
sits in the raid error or the actual libata/driver area (more probable)

I have 7 SATA disks hanging of an 8 port controller which uses the 
sata_mv driver.

I create a raid 5 array consisting of 6 disks (using 1 full disk 
partition) and 1 spare

The array builds fine - although it takes 300 minutes so its not a quick 
process to run through tests.

md6 : active raid5 sdh[5] sdi[6](S) sdg[4] sdf[3] sde[2] sdd[1] sdc[0]
      1225586560 blocks level 5, 64k chunk, algorithm 2 [6/6] [UUUUUU]

as you can see, all looking good. sdi is marked as the spare./dev/md6:
        Version : 00.90.03
  Creation Time : Sat Dec 31 16:23:11 2005
     Raid Level : raid5
     Array Size : 1225586560 (1168.81 GiB 1255.00 GB)
    Device Size : 245117312 (233.76 GiB 251.00 GB)

big raid5 trouble

Hello all!

I'm not sure, that is this the right place to ask such question, but I'm 
in a big trouble with my RAID5 array.

My last chance to get any of the data back stored in this array, is to
"unspare" a spare disk, that is untouched since the removal.

I googled but can't find neither a documentation nor a specification where 
and how the spare flag is stored on a disk. Can you please help me?

Thanks a lot.
--

-- 
Czigola, Gabor
-
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

Re: big raid5 trouble

Czigola Gabor wrote:

> Hello all!
>
> I'm not sure, that is this the right place to ask such question, but 
> I'm in a big trouble with my RAID5 array.
>
> My last chance to get any of the data back stored in this array, is to
> "unspare" a spare disk, that is untouched since the removal.
>
> I googled but can't find neither a documentation nor a specification 
> where and how the spare flag is stored on a disk. Can you please help me?
>
> Thanks a lot.

I don 't think that will help you, per se.  Why do you say it is your 
last chance? If you have n-1 disks OK, then you may be OK.  If not, a 
spare will not help.  Can you tell us more?
b-

-
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

Subject: where is the spare drive?

Hello, list,

I found something interesting when i try to create a brand new array on
brand new drives....

1. The command was:
mdadm --create /dev/md1 --level=5 --raid-devices=12 --chunk=1024 \
/dev/hda2 /dev/hdb2 /dev/hdc2 /dev/hdd2 \
/dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd2 \
/dev/sde2 /dev/sdf2 /dev/sdg2 /dev/sdh2

2. The proc/mdstat:
Personalities : [linear] [raid0] [raid1] [raid5] [multipath] [raid6]
[raid10] [f
aulty]
md1 : active raid5 sdh2[12] sdg2[10] sdf2[9] sde2[8] sdd2[7] sdc2[6] sdb2[5]
sda
2[4] hdd2[3] hdc2[2] hdb2[1] hda2[0]
      2148934656 blocks level 5, 1024k chunk, algorithm 2 [12/11]
[UUUUUUUUUUU_]
      [=>...................]  recovery =  5.7% (11308928/195357696)
finish=234.
3min speed=13088K/sec

unused devices: <none>

3. The mdadm -D
/dev/md1:
        Version : 00.90.02
  Creation Time : Sat Dec 31 12:59:51 2005

Re: Raid source 2TB limit question + system upgrade plan

> > Few months ago i got one patch from you to let the linear raid handle
>2TB
> > devices.
> > At this point  i not to able to test it, because i dont have money to
buy
> > the upgrade.
> >
> > The question is this:
> >
> > If i switch from i386 to x86_64, the patch will be unneccesary or still
need
> > the kernel, to handle the big drive?
>
> You need it on x86_64 as well, though it you are running 2.6.14 or
> later, the patch is already there.
>
> NeilBrown

Hello, Neil,

Now it is the time to upgrade my system from 8TB to 13.2TB. 

(Simple reminder if somebody forget, or missed something:
i use 4 disk node with NBD.
Each nodes are 2TB (11x200GB Raid5) now, and in the concentrator i use one
raid0 to join the nodes to one big raid array.
Some months ago, when i try to build this system, found one limit.
The linear array cannot import the 8TB array, caused by its size.)

I want to ask you, Neil, about possible limitations....

Re: big raid5 trouble

On Sun, 1 Jan 2006, berk walker wrote:

> I don 't think that will help you, per se.  Why do you say it is your last 
> chance? If you have n-1 disks OK, then you may be OK.  If not, a spare will 
> not help.  Can you tell us more?
> b-
>

So there is a RAID5 array with 4 disks. I had a long power failure, and 
during the boot sequence, I saw that the 4th disk got marked as non fresh. 
I started the process that should bring the 4th disk back in the array, 
but during this the 3th disk died. The 4th disk is now marked as spare.

Meanwhile a found the 4k superblock on the disk (strace mdadm -E), and I 
got - from the source of mdadm - the exact location of the spare flag. But 
I guess, I have to recalc the correct checksum of the new superblock.(?)

--

-- 
Czigola, Gabor

-
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

Problem migrating to bootable RAID1 on Debian

Hi all,

I've been working on getting my heavily upgraded Debian distro to have
mirrored /, /boot, /usr, /var and swap partitions.  My /home and
/local are already built on LVM2 volumes ontop of a pair of mirrored
120gb disks (md0).  I just fixed the RAID autodetection for that MD
volume by changing the partition from LVM to Raid Autodetect.  Duh...
Now I don't need anything in /etc/mdadm/mdadm.conf that I can see.

In any case, I'm following the instructions given on:

  http://www.debian-administration.org/articles/238

which is pretty decent, but does gloss over some details, such as
debugging boot problems and testing.  :] And of course, when you try
to convert a single disk into a mirrored bootable disk, it's sometimes
painful.  No lost data yet... but I'd hate to have to rebuild.

Details:

I've got a Dell Precision 610, Dual 550Mhz PIII Xeon processors, 768mb
of RAM.  Builtin SCSI controllers, with a pair of 18gb SCSI disks as
/dev/sda and /dev/sdb.  Currently /dev/sda# is what I'm using.  I've
also got an HPT302 controller with the pair of 120gb disks for data,
using GRUB to manage booting.  No other OSes installed on here.  Now
running kernel 2.6.15-rc7 on it.  Ran 2.6.15-rc1 for about a month
without problems.   Software versions:

	grub	0.97

Re: big raid5 trouble

Czigola Gabor wrote:

> On Sun, 1 Jan 2006, berk walker wrote:
>
>> I don 't think that will help you, per se.  Why do you say it is your 
>> last chance? If you have n-1 disks OK, then you may be OK.  If not, a 
>> spare will not help.  Can you tell us more?
>> b-
>>
>
> So there is a RAID5 array with 4 disks. I had a long power failure, 
> and during the boot sequence, I saw that the 4th disk got marked as 
> non fresh. I started the process that should bring the 4th disk back 
> in the array, but during this the 3th disk died. The 4th disk is now 
> marked as spare.
>
> Meanwhile a found the 4k superblock on the disk (strace mdadm -E), and 
> I got - from the source of mdadm - the exact location of the spare 
> flag. But I guess, I have to recalc the correct checksum of the new 
> superblock.(?)
>
The "spare" disk would be just that, spare, like a spare tire for a car, 
pressure is up, ready to go.  Each drive contained unique information, 
which could be reconstructed from the remaining n-1 drives.  You now 
have 1 drive "the spare" with no data, and an n-2  array.  You will 
probably lose data, though the 3rd disk might have had errors in an 
unused area.  You can FORCE the drives back into an array if things 
aren't too trashed.  I can not tell what is the safest way to do this, 
but someone here may.