FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 06-12-2008, 05:28 PM
Les Mikesell
 
Default raid1 disk format?

Scott Silva wrote:




I'm curious as to why 2 complete dd'd copies don't pair at boot.
One comes up running and it does work to mdadm --add the partner
partitions and after the resync they do automatically pair at boot.


Are they dd copies of the different nodes (IE.. dd copy of sda paired
with dd copy of sdb)?


No - what was sda was dd'd twice with the dups put in sda and sdb.

That is why it didn't work. The superblock knows which drive it was on,
and knows if there are dupes.


But I thought the locations were re-detected at boot/assembly time.

The other question is whether it is possible to change the uuid while
the system is running or if it would have to be done from a CD boot.
I've cloned several machines from one initial setup and if copies of the
disks ever find their way back into one box I'd prefer not to have the
wrong set try to re-sync.


--
Les Mikesell
lesmikesell@gmail.com

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 06-12-2008, 06:08 PM
Scott Silva
 
Default raid1 disk format?

on 6-12-2008 10:28 AM Les Mikesell spake the following:

Scott Silva wrote:




I'm curious as to why 2 complete dd'd copies don't pair at boot.
One comes up running and it does work to mdadm --add the partner
partitions and after the resync they do automatically pair at boot.


Are they dd copies of the different nodes (IE.. dd copy of sda
paired with dd copy of sdb)?


No - what was sda was dd'd twice with the dups put in sda and sdb.

That is why it didn't work. The superblock knows which drive it was
on, and knows if there are dupes.


But I thought the locations were re-detected at boot/assembly time.

The other question is whether it is possible to change the uuid while
the system is running or if it would have to be done from a CD boot.
I've cloned several machines from one initial setup and if copies of the
disks ever find their way back into one box I'd prefer not to have the
wrong set try to re-sync.


The locations can re-detect, but I still think it will stop if it detects 2
identical superblocks.
I don't think you can change the UUID of a running array, and I'm not sure if
you can do it easily on a stopped array. I think the safest thing is to use
the --add to join the pair. Since they are dd clones, the sync should be
fairly fast. Just be careful.


I know that it seems like an easy way to clone machines, but I think there are
better and safer ways to clone machines.


--
MailScanner is like deodorant...
You hope everybody uses it, and
you notice quickly if they don't!!!!

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 06-12-2008, 06:24 PM
Les Mikesell
 
Default raid1 disk format?

Scott Silva wrote:


I'm curious as to why 2 complete dd'd copies don't pair at boot.
One comes up running and it does work to mdadm --add the partner
partitions and after the resync they do automatically pair at boot.


Are they dd copies of the different nodes (IE.. dd copy of sda
paired with dd copy of sdb)?


No - what was sda was dd'd twice with the dups put in sda and sdb.

That is why it didn't work. The superblock knows which drive it was
on, and knows if there are dupes.


But I thought the locations were re-detected at boot/assembly time.

The other question is whether it is possible to change the uuid while
the system is running or if it would have to be done from a CD boot.
I've cloned several machines from one initial setup and if copies of
the disks ever find their way back into one box I'd prefer not to have
the wrong set try to re-sync.


The locations can re-detect, but I still think it will stop if it
detects 2 identical superblocks.
I don't think you can change the UUID of a running array, and I'm not
sure if you can do it easily on a stopped array. I think the safest
thing is to use the --add to join the pair. Since they are dd clones,
the sync should be fairly fast. Just be careful.


Yes, the sync does work fine and once finished the set will always start
itself.


I know that it seems like an easy way to clone machines, but I think
there are better and safer ways to clone machines.


You can't beat dd for getting everything exactly the same regardless of
what you changed - or just splitting the mirrors and letting each sync
to new partners but then you have to reinstall grub. I prefer
clonezilla for non-raid configurations but most of the machines I care
about are configured with raid1.


--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 06-12-2008, 07:14 PM
"Ross S. W. Walker"
 
Default raid1 disk format?

Les Mikesell wrote:

> You can't beat dd for getting everything exactly the same regardless of
> what you changed - or just splitting the mirrors and letting each sync
> to new partners but then you have to reinstall grub. I prefer
> clonezilla for non-raid configurations but most of the machines I care
> about are configured with raid1.

Well, actually dd isn't so good in this area. dd will do the whole disk
no matter how much data is actually stored on it and for a 500GB disk
that can take a lot of time. It also doesn't take into consideration
any disk geometry differences.

A better way is to use kickstart script to automate a network install
and then to use dump/restore to load the user/application data back.

With remote access cards and vnc kickstart installs this can even be
done remotely on a headless server even without a technician present
to power it on or off.

-Ross

__________________________________________________ ____________________
This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 06-12-2008, 07:50 PM
Les Mikesell
 
Default raid1 disk format?

Ross S. W. Walker wrote:


You can't beat dd for getting everything exactly the same regardless of
what you changed - or just splitting the mirrors and letting each sync
to new partners but then you have to reinstall grub. I prefer
clonezilla for non-raid configurations but most of the machines I care
about are configured with raid1.


Well, actually dd isn't so good in this area. dd will do the whole disk
no matter how much data is actually stored on it and for a 500GB disk
that can take a lot of time.


Sure, but it isn't human time. I just give the command and come back later.


It also doesn't take into consideration
any disk geometry differences.


I happen to have a lot of identical disks in swappable carriers.


A better way is to use kickstart script to automate a network install
and then to use dump/restore to load the user/application data back.


Sounds like more work to me. Besides figuring out the kickstart options
you need an up-to-the-minute dump made beforehand and there's always
some risk in restoring running programs unless you use a program like
rsync that creates a tmp name, then renames when complete. And there's
some work to sort out what you can restore and what you can't.



With remote access cards and vnc kickstart installs this can even be
done remotely on a headless server even without a technician present
to power it on or off.


Shipping a box of disks for someone else to swap in works for me, and it
doesn't matter if you decide to drastically change OS's between swaps.
You do have to deal with the way NIC detection has changed across Centos
versions, though.


--
Les Mikesell
lesmikesell@gmail.com

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 06-12-2008, 09:39 PM
"William L. Maltby"
 
Default raid1 disk format?

On Thu, 2008-06-12 at 15:14 -0400, Ross S. W. Walker wrote:
> Les Mikesell wrote:
>
> > You can't beat dd for getting everything exactly the same regardless of
> > what you changed - or just splitting the mirrors and letting each sync
> > to new partners but then you have to reinstall grub. I prefer
> > clonezilla for non-raid configurations but most of the machines I care
> > about are configured with raid1.
>
> Well, actually dd isn't so good in this area. dd will do the whole disk
> no matter how much data is actually stored on it and for a 500GB disk
> that can take a lot of time. It also doesn't take into consideration
> any disk geometry differences.

True. But with a small amount of scripting (assuming some experience
like I had at the time I did this professionally), you can quickly
produce a fairly flexible, automated, fast and reliable process that
accomplishes the task.

I'll elaborate a little below.

> <snip>

> -Ross
> <snip sig stuff>

First, as to speed. Using a blksize= parameter (I used a cyl size as my
"standard" unit of transfer), the number of system calls is reduced and
the speed of the hardware becomes the limiting factor. Back when I
tested this (old slower low-single-digit GB drives, circa 2000-2002),
very large speedups were seen. I don't recall the percentages.

Second, "copies the whole disk ...". Here is where a small amount of
scripting becomes useful. You can copy only specific partitions. If the
whole disk is a single partition, some stats gathered by various
utilities can determine used counts, and a combination of shrinking the
file system (didn't have a shrink ability back when) and (if desired)
shrinking the partition can be used to "compact" the source.

In conjunction with sfdisk to both gather configuration information and
generate new configuration (via scripts), you can reduce the source
copied to very close to just that needed.

In the final step, this is engendered via the "count=", "skip=" and
"seek=" parameters to dd.

This was implemented in a NAS product as part of the RAS process that
could not predict the specifications of HDs that might be replaced in
the field.

Lastly, as to geometry differences, again sfdisk is your friend. What I
can not address is how to integrate this with raid - no experience
there. I do presume that one knowledgeable in that area could also
automate that.

If this sounds like a lot of work, it's not really. This part of my
effort was minimal. The large part was creation of the boot CD,
interfacing with the custom hardware timeout facility for auto-reboot to
a fallback device and implementing and testing the software install and
rejoin with the cluster.

Oh... and the constantly changing specs (list of requirements kept
changing as they saw opportunities I brought to the table - their *IX
experience was quite limited).

HTH
--
Bill

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 07:42 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org