Re: Linux: Einzelne Festplatte nach RAID1 erweitern? dm-cache? ZFS?

[Raphael Eiselstein <rabe@xxxxxxxxx>]

On Mon, May 27, 2013 at 08:13:57PM +0200, Marc Haber wrote:
> On Mon, May 27, 2013 at 07:57:54PM +0200, Raphael Eiselstein wrote:
> > Variante 1: Ist es moeglich hier nachtraeglich und verlustfrei ein Mirror 
> > draus zu bauen? Falls ja, genaue Vorgehensweise? mdadm? Wie genau?
> 
> 1 Zweite Platte dazustecken
> 2 RAID 1 mit nur einem Member bauen
> 3 Daten umkopieren
> 4 Erste Platte als zweites Member in das RAID hinzunehmen.

Ich habs jetzt mal in einer VM mit dem "Ich will aber" versucht und bin
wohl auch ein Stueck weit gekommen.

Das Testsetup kennt ein sdb und ein gleich grosses sdc. sdb1 nmmt dabei
die Rolle der bereits vorhandenen Platte ein.

Der Einfachheit halber habe ich diese mit ext4 formatiert und eine
handvoll Daten hinkopiert:

    3  fdisk /dev/sdb
    4  mkfs.ext4 /dev/sdb1 
    7  mkdir /data
    9  mount /dev/sdb1 /data
   13  cp -av /var/cache/apt/ /data/
   14  umount /data 

Anschliessend per fdisk den Partitionstyp auf "fd" geaendert und aus der
*bestehenden* Platte sdb1 ein RAID1 mit genau einem device (naemlich
sdb1) erzeugt:

   22  fdisk /dev/sdb
   26  mdadm --create --metadata=1.0 --raid-devices=1 --level=mirror --name=data --force /dev/md0 /dev/sdb1
   27  cat /proc/mdstat 

mdadm: /dev/sdb1 appears to contain an ext2fs file system
    size=8387584K  mtime=Tue May 28 23:59:14 2013
Continue creating array? y
mdadm: array /dev/md0 started.
root@mdtest:~# cat /proc/mdstat 
Personalities : [raid1] 
md0 : active (auto-read-only) raid1 sdb1[0]
      8387520 blocks super 1.0 [1/1] [U]
      
unused devices: <none>


Danach liess sich das ext4 nicht mehr mounten, weil das md0 ein paar
Bloecke kleiner ist als das sdb1.

   28  mount /dev/md0 /data/
   29  mount -t ext4 /dev/md0 /data/
--> Failed.

Dann habe ich mich spontan daran erinnert, dass man ext4 auch
verkleinern kann:
   41  resize2fs /dev/md0
   42  mount /dev/md0 /data/

--> klappt und alle Daten sind noch da.


Dann habe ich die Platte sdc vorbereitet und mit einer identischen
Geometrie gebau wie sdb:

   43  fdisk /dev/sdc

... und das sdc1 in das md0 mit aufgenommen.

   47  mdadm --add /dev/md0 /dev/sdc1 
   48  cat /proc/mdstat 

... Leider nicht mit dem erwarteten Resultat, denn es scheint nicht zu
syncen:
------------------------------------------------
root@mdtest:~# cat /proc/mdstat 
Personalities : [raid1] 
md0 : active raid1 sdc1[1](S) sdb1[0]
      8387520 blocks super 1.0 [1/1] [U]
      
unused devices: <none>
------------------------------------------------

Wie habe ich obigen Output zu lesen? Was bedeutet (S) hinter sdc1?

Sorry, wenn ich einen offensichtlichen Fehler gemacht habe, aber ich
habe bisher kaum eigene Erfahrungen damit gesammelt.

Abgesehen von der leichten Verwirrung, die ein ext4 mit der Situation
hatte, ich nehme an, dass ein dm-crypt mit einem verkleienerten
Blockdevice klarkommt (werde das aber sicher vorher testen). LVM *sollte* 
damit auch klarkommen, wenn die VolumeGroup kleiner wird, solange die 
darin befindlichen LogicalVolumes nicht den gesamten Platz beanspruchen.


Mein Trick, der hier (scheinbar) geklappt hat ist --metadata=1.0, welches
laut manpage dazu fuehrt, dass die Metadaten am *ENDE* des Devices
abgelegt werden. 

Es gab sicher einen Grund, warum man das bei der neueren Version 1.2 dann 
wieder geaendert hat, aber wenn --metadata=1.0 kein Risiko darstellt (Daten 
ganz hinten fallen bestimmt mal runter), dann sollte es doch eine valide 
Methode sein, oder?

Any Ideas?

Gruss
Raphael

PS:  
> Schoener waer's, wenn Du das dmcrypt in eine LV gelegt haettest. Dann
> waere Schritt 3 per pvmove gegangen.

Wenn ich dm-crypt *in* LogicalVolumes gelegt haette, haette ich den
Vorteil, dass ich nicht alle LVs verschluesselt haette aber auch den
Nachteil, dass ich beim booten oder mounten dann fuer alle
verschluesselten LVs Passwoerter eintippen muss, die ich
mir selbstverstaendlich alle merken muss, vor allem welches zu welchem.


-- 
Raphael Eiselstein <rabe@xxxxxxxxx>               http://rabe.uugrn.org/
xmpp:freibyter@xxxxxx  | https://www.xing.com/profile/Raphael_Eiselstein   
GnuPG:                E7B2 1D66 3AF2 EDC7 9828  6D7A 9CDA 3E7B 10CA 9F2D
.........|.........|.........|.........|.........|.........|.........|..



-- 
UUGRN e.V. http://www.uugrn.org/
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: https://wiki.uugrn.org/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/