slacky.eu

Ciao ragazzi,
ho finalmente creato il raid sul mio mediacenter,e funziona quasi tutto bene.
L'unico problema è il resume da ibernazione(suspend to disk).
Premetto che senza raid il sistema funziona che è una meraviglia.
Ho creato tutte le partizioni in raid 1 compresa ANCHE la swap.
Dopo aver impostato in lilo.conf il device corretto (/dev/md2 nel mio caso) ed un riavvio,provo ad eseguire il suspend.
La macchina si sospende correttamente.Il log di pm-suspend è perfetto.Nel ripristino arrivano i guai:

Codice: Seleziona tutto

md: created md2
md: bind<sdb3>
md: bind<sda3>
md: running: <sda3><sdb3>
raid1: md2 is not clean -- starting background reconstruction
raid1: raid set md2 active with 2 out of 2 mirrors
md2: detected capacity change from 0 to 2048000000

In pratica al riavvio,il kernel trova dei problemi sulle partizioni di md2 ed esegue un resync dell'array.Terminata questa procedura,prosegue con il boot regolare e poi esegue chiaramente un fsck sulla partizione / .

Questo è il mio lilo.conf:

Codice: Seleziona tutto

# LILO configuration file                              
# generated by 'liloconfig'                            
#                                                      
# Start LILO global section                            
boot = /dev/md0                                        
raid-extra-boot=mbr-only                               
compact        # faster, but won't work on all systems.
# Bitmap in BMP format: 640x480x8                      
  bitmap = /boot/slack.bmp                             
# Menu colors (foreground, background, shadow, highlighted
# foreground, highlighted background, highlighted shadow):
  bmp-colors = 255,0,255,0,255,0
# Location of the option table: location x, location y, number of
# columns, lines per column (max 15), "spill" (this is how many
# entries must be in the first column before the next begins to
# be used.  We don't specify it here, as there's just one column.
  bmp-table = 60,6,1,16
# Timer location x, timer location y, foreground color,
# background color, shadow color.
  bmp-timer = 65,27,0,255
# Standard menu.

# Append any additional kernel parameters:
append=" root=/dev/md0 vt.default_utf8=0 resume=/dev/md2"
prompt
timeout = 50
vga = 773
# vga = normal
# ramdisk = 0     # paranoia setting

image = /boot/vmlinuz-2.6.32.7-smp
  root = /dev/md0
  label = 2.6.32.7
  read-only

# Linux bootable partition config begins
image = /boot/vmlinuz-2.6.32.5-smp
  root = /dev/md0
  label = 2.6.32.5
  read-only

image = /boot/vmlinuz
  root = /dev/md0
  label = Slack
  read-only  # Partitions should be mounted read-only for checking
# Linux bootable partition config ends

Come metodo di sospensione uso quello vanilla del kernel,perchè ha sempre funzionato alla perfezione su questa macchina.
Idee?

Leggendo un how-to per Arch, noto che bisogna specificare al kernel anche come sono composti i vari arrai raid che si hanno, oltre alla partizione da usare per il resume.
Ti riporto lo spezzone incrimato:

Codice: Seleziona tutto

# (0) Arch Linux
title  Arch Linux
root   (hd0,0)
kernel /vmlinuz26 root=/dev/md2 resume=/dev/md0 ro md=0,/dev/sda2,/dev/sdb2 md=2,/dev/sda5,/dev/sdb5 vga=773
initrd /kernel26.img

È riferito a GRUB, ma i parametri da specificare al kernel rimangono invariati tra GRUB e LILO.
Come vedi, oltre a specificare la partizione di root e la partizione di resume, specifica anche la composizione fisica degli array md0 ed md2.

Credo che come parametro sia superfluo,visto che con il superblock e l'autodetect,il kernel è in grado di ricomporre l'array autonomamente.
Ho visto altri esempi di configurazione e nessuno specificava la struttura dell'array nel bootloader.Poi magari mi sbaglio.

Io la swap non la tengo su raid, uso le due partizioni singolarmente:

Codice: Seleziona tutto

/dev/sda6        swap             swap        defaults         0   0
/dev/sdb6        swap             swap        defaults         0   0

Ho sempre pensato, magari sbagliando, che le partizioni di swap in raid software potessero generare rallentamenti.
Il "resume" lo faccio su sda6.
Nessun problema.
Saluti,
MuRdOcK

Ho capito il problema.
Il fatto è che congelando il sistema ad un determinato momento x lo stato di un array non sempre è marcato come "clean".Pertanto quando il sistema viene riattivato,il kernel non trova l'array nello stato "clean" e inizia subito il resync,azzerando l'immagine per il resume.
Trucco:
In initrd(quindi è obbligatorio in questo caso sigh!) si deve impostare in uno script di avvio questo comando:

Codice: Seleziona tutto

echo 1 > /sys/module/md_mod/parameters/start_ro

In tal modo gli array partono in read-only ,il resync non può avvenire ed il resuming ha successo.Alla prima scrittura su un array lo stato di read only viene disattivato ed il sistema funziona regolarmente.
In questa mailing list di Debian viene spiegato meglio questo problema
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=415441
Ovviamente è ancora da testare

Con la modifica di cui sopra, funziona quasi.
Riesco ad effettuare correttamente il resume senza far partire il resync.
Unico neo:ci mette davvero troppo!!!.Oltre i 2 minuti per recuperare circa 140 Mib di Ram.
Inizialmente è veloce,ma poi verso il 30-40% del recupero, la velocità si abbassa notevolmente.
Nella configurazione precedente(prima del raid insomma) era molto veloce e funzionava sempre bene.
Ho utilizzato lo stesso kernel (2.6.32) con lo stesso config.L'unica differenza adesso è l'utilizzo di un'initrd e di un device raid.
Pensate che esista qualche tuning da effettuare?Non ho molta esperienza di initrd.Ho googlato tutto il pomeriggio,ma non ho trovato nessun aiuto a riguardo

slacky.eu

Resume da software raid

Resume da software raid

Re: Resume da software raid

Re: Resume da software raid

Re: Resume da software raid

Re: Resume da software raid

Re: Resume da software raid