Re: just how dangerous is this??

On Tue, May 28, 2002 at 09:20:39PM +0200, Danilo Godec wrote:

On Tue, 28 May 2002, James Fillman wrote:

...

I think this shouldn't work at all - have you rebooted the machine yet?

It's not quite clear how the mirrors reconstruct if one of the disks
(partitions) already has a filesystem on it, but I'm almost sure it's not
ment to reconstruct it properly...

Either it reconstructs it "right" or it does it "wrong".  It seems in his case
it did it right.   Lucky him.

Hoever, the persistent superblocks will overwrite the last few KB of his
*filesystem* on each partition.   So things *may* seem to work, but the
system will fail horribly later.  After an fsck the RAID suprblocks will
be damaged.  After another mkraid the filesystem will be damaged again.

AFAIK making a filesystem on a Linux SW RAID array is somewhat different
from making it on a 'normal' disk, so while you may end up with a
filesystem, it will probably be full of errors.

Yep.

How does your raidtab look like?

The 'right' way of doing this is:

- create a 'degraded' mirror with sda* partitions marked as 'failed'
- copy all the data from sda* partitions to the appropriate mirrors
  (/dev/md*)
- modify /etc/fstab on the mirrored filesystem to use the mirrors
- reboot, use filesystems on the mirror (root=/dev/md?)
- hot add sda* partitions to approprate mirrors (using raidhotadd or
  mdadm)
- wait for the reconstruction to finish
- make sure that both disks have the boot loader installed in MBR, so they
  can both be used for booting

Yep.

This should be it. Unfortunately, this procedure is not that easy to
script.

I suppose that if the installation kernel (the one booted during the installation
process) could be made to support RAID (with autodetection), you could just create
the RAID arrays prior to installation, and then simply install on those arrays.

But that may require some hacking of the SuSE install disk...

quoted

the mkraid command warns me that it will delete all the data on the partitions
when creating the mirrors, but it doesn't.

I guess it doesn't delete the data, it destroys it... :)

Just a small amount of it.  It "almost doesn't totally f*ck up the system"   ;)

quoted

What sort of implications am I looking at with this? Will it be unstable?

I am no super-expert or guru, but I'd say YES. Try booting the system with
a rescue disk and run e2fsck on your mirrored filesystems. If this goes
through OK... Well, then I might be wrong and it's OK to do this with new
kernel/raidtools...

I'd say you're right about the failures.

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, 28 May 2002, [iso-8859-1] Jakob Østergaard wrote:

Either it reconstructs it "right" or it does it "wrong".  It seems in
his case it did it right.  Lucky him.

Hoever, the persistent superblocks will overwrite the last few KB of his
*filesystem* on each partition.   So things *may* seem to work, but the
system will fail horribly later.  After an fsck the RAID suprblocks will
be damaged.  After another mkraid the filesystem will be damaged again.

You should be able to pre-plan by creating initial ext2 file systems that
are smaller than the partition size. You can do this by specifying the
number of blocks in the file system when you run mke2fs. 

mke2fs [options] device blocks

You should be able to calculate the eventual location of the md superblock
and select an appropriate block size for each partition to insure that the
superlbock and the filesystem do not overlap. 

Even if you've had sucess thus far, it's likely that problems will arise
as the filesystem fills up-- when the last blocks are allocated, and they
overlap the md superblock.

This probably isn't worth the effort unless you are doing multiple
installs with the same partition layout and hardware, but it seems that it
might be the case here.

I think the formula should be something like:

blocks - (blocks % 64) - 64 = md offset

That's for 1k blocks... ( like from fdisk -l)

I'm a bit lazy to double check, but I think that formula works.

Then when creating a filesystem divide by block size and create a file
system that's the right size... 

---
Derek Vadala, derek@cynicism.com, http://www.cynicism.com/~derek

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