Tag Archives: disk

Comprimiamo al massimo i qcow2

Ecco un breve tutorial per comprimere al massimo le imamgini qcow2.

Le fasi principali necessarie sono:

  1. Montare il filesystem in read-only oppure attivare il device sull’host
  2. Eseguire zerofree
  3. Ricomprimere l’immagine

I requisiti sono:

  1. zerofree (http://intgat.tigress.co.uk/rmy/uml/index.html oppure yum install zerofree)
  2. qemu-img (disponibili dal pacchetto qemu)

Opzionalmente

  • qemu-nbd (disponibili dal pacchetto qemu)
  • Modulo del kernel nbd

Il principio di funzionamento di zerofree sta nel sovrascrivere con zero tutti i blocchi del filesystem non utilizzati, così che si possa sfruttare al meglio la funzionalità compress del formato qcow2. Per maggiori dettagli vi rimando al stito di zerofree (http://intgat.tigress.co.uk/rmy/uml/index.html) e qcow2 (http://people.gnome.org/~markmc/qcow-image-format.html).

Per utilizzare zerofree su un immagine qcow2 esistente si possono applicare due soluzioni:

  1. Eseguire zerofree all’interno del guest. Questo richiede che il filesystem su cui si vuole operare sia in read-only e che all’interno del guest sia disponibile il programma zerofree.
    Per rimontare un filesystem in read-only normalmente è sufficiente, avendo un accesso locale alla VM e non via SSH, entrare nel runlevel 1 (init 1) ed eseguire il comando

    mount -o remount,ro /
  2. Eseguire zerofree dall’host. Le immagini qcow2 non possono essere montate direttamente nell’host tramite un offset di mount o tramite kpartx; per questo motivo ci server il supporto al Network Block Device alias nbd. Ha come vantaggio la possibilità di eseguire tutto dall’host senza avviare le VM e che è necessario avere il comando zerofree solo sull’host.

Nello specifico utilizzeremo la soluzione numero 2.
Continue reading

Creare un volume LVM

Supponendo di voler creare un volume LVM nel disco sdd per prima cosa inizializziamo lo spazio

pvcreate /dev/sdd
pvcreate initializes PhysicalVolume for later use by the  Logi‐
cal  Volume  Manager  (LVM).  Each PhysicalVolume can be a disk
partition, whole disk, meta device, or loopback file.

Successivamente creiamo il gruppo di volumi. Come estenzione fisica del volume (non quella virtuale che poi sarà quella realemente disponibile) è suggerito un valore di 32MB

vgcreate -s 32M backup /dev/sdd
vgcreate creates a  new  volume  group  called  VolumeGroupName
using the block special device PhysicalDevicePath.

Infine creiamo il volume logico vero e proprio assegnadogli una dimensione e un nome. Tale dimensione potrà venire estesa successivamente con lvextend.

lvcreate -L200G -nhomebk backup
lvcreate creates a new logical volume in a volume group  (  see
vgcreate(8),  vgchange(8)  ) by allocating logical extents from
the free physical extent pool of that volume group.

A questo punto il nuovo volume sarà disponibile come device attraverso il path /dev/gruppo/nomevolume pronto per poter essere formattato.

Ricordo che LVM può essere creato anche all’interno di una partizione o di un’immagine disco.

Riferimenti

  • man pvcreate
  • man vgcreate
  • man lvcreate

Montare immagini raw partizionate

Per montare un immagine RAW oppure una partizione e/o LV contenente una VM o un insieme di partizioni è sufficiente avere installato kpartx

yum -y install kpart

A questo punto è possibile sfruttare /dev/mapper per mappare le partizioni del volume

kpartx -av /path/to/file_or_lv

le partizioni compariranno sotto forma di devices

ls /dev/mapper/
file_or_lv1
file_or_lv2
file_or_lvN

a questo punto è possibile montare ogni singola partizione come consueto

mount /dev/mapper/file_or_lv1 /mnt/ext

per rimuovere la mappatura è sufficiente eseguire

kpartx -d /path/to/file_or_lv

Dove sono le viti?

L’HP MicroServer offre un totale di 4 bay da 3.5″ per hardisk LFF e 1 bay per unità da 5.25″ (unità ottiche o a nastro). Normalmente solo un cassettino degli HDD è popolato, gli altri tre sono vuoti.

Qual’ora si volesse aggiungere ulteriori dischi HP fornisce tutti gli strumenti e i materiali necessari al montaggio. Dietro allo sportellino frontale infatti si trovano due set di viti (per 3.5″ e per 5.25″) e la brugola adatta all’utilizzo con le viti fornite (serve anche per poter smontare la mainboard ndr.).

Dal manuale:

Il post è dedicato a Michele

Creare RAID 1 con mdadm

Ecco il primo, breve, tutorial per la creazione di un array mirroring RAID.

Per prima cosa occorre preparare le partizioni che andranno in mirroring su ogni unità; non è indispensabile che i dischi coinvolti siano identici, ma è consigliato.
Per creare le partizioni è possibile utilizzare svariati tool quali fdisk, cfdisk e parted/gparted nel caso si stia creando un partizionamento MBR oppure gdisk e parted/gparted per il più evoluto partizionamento GPT.
Le partizioni vanno create della stessa dimensione (blocchi) per gli n dischi coinvolti.
Il tipo di partizione è 0xfd per l’MBR o fd00 per GPT.

A questo punto è possibile cominciare la vera è propria creazione del RAID mediante mdadm.

Per prima cosa assicurarsi che il superblocco che contiene le informazioni del RAID software sia vuoto (capita spesso con dischi già utilizzati in catene md che tale blocco contenga ancora informazioni vecchie).

Supponiamo che le partizioni da cui creare il RAID siano sdb1 e sdc1:

mdadm --zero-superblock /dev/sdb1
mdadm --zero-superblock /dev/sdc1

Per creare la catena è sufficiente lanciare il comando

mdadm --create --verbose --assume-clean --level=1 --raid-devices=2 /dev/md0 /dev/sdb1 /dev/sdc1

In dettaglio:

  • –create è autoesplicativo
  • –verbose aumenta il dettaglio in output dal comando
  • –assume-clean è importante, perché evita che l’array venga ricostruito e quindi fatto il resync. Su partizioni di grandi dimensioni può metterci molto tempo. E’ da utilizzare solo per la creazione di nuovi array vuoti
  • –level=1 specifica che si tratta di un mirroring e quindi un RAID di tipo 1
  • –raid-devices=2 numero dei devices da aggiungere all’array
  • /dev/md0 è il nome del device che punterà al nuovo array
  • /dev/sdb1 e /dev/sdc1 sono le partizioni che andranno a formare l’array

Al termine del comando l’array sarà attivo e pronto all’utilizzo.

# cat /proc/mdstat
Personalities : [raid1] 
 
md0 : active raid1 sdc1[1] sdb1[0]
      335543160 blocks super 1.2 [2/2] [UU]
 
unused devices: <none>

Ancora un paio di note: per prima cosa conviene attivare il supporto bitmap per poter ricostruire l’array più velocemente

mdadm --grow --bitmap=internal /dev/md0
Personalities : [raid1] 
 
md0 : active raid1 sdc1[1] sdb1[0]
      335543160 blocks super 1.2 [2/2] [UU]
      bitmap: 1/3 pages [4KB], 65536KB chunk
 
unused devices: <none>

Il comando

mdadm -Es >> /dev/mdadm.conf

è consigliato, ma tuttavia non necessario nel caso che il file /etc/mdadm.conf contenga già la riga

AUTO +imsm +1.x -all

Western Digital aggressive head parking

Ho da qualche giorno acquistato due Western Digital Caviar Green da 2TB (modello EARS) da montare in un MicroServer (non mio, io ho due Seagate Barracuda LP).
Ho subito notato che non è possibile tramite hdparm gestire l’APM (advanced power management) e che il disco effettua spessissimo il parcheggio delle testine.
Il controllo con smartctl ha subito evidenziato un notevole aumento del valore load_cycle_count. Se il contatore raggiunge valori molto alti viene meno l’affidabilità del disco (sono garantiti 300.000 cicli, ma meno sono e meglio è).

Cercando con google ho scoperto che tali dischi hanno impostato a livello di firmware un timeout per il parcheggio di soli 8 secondi! Non mi è stato possibile effettuare l’override delle impostazioni con hdparm: se il parametro -B255 da errore (vedi sopra) il parametro -S240 (che imposta il timeout a 20 minuti) non sortisce effetti.

Ho scoperto che anche l’unità dell’HP Mini (sempre un WD, ma un Scorpio Blu) è soggetta allo stesso problema (qui addirittura ogni 4 secondi!): in questo caso mi ero accorto del comportamento troppo aggressivo del firmware, ma ero riuscito ad arginare il problema disabilitando l’APM con

hdparm -B255 /dev/sda

Sempre grazie a google ho trovato la soluzione definitiva sia per i Green che per lo Scorpio: si tratta dell’utility WDidle 3.1 che ufficialmente è per altri modelli sempre WD, ma che almeno con i miei esemplari funziona a meraviglia. Continue reading

MicroServer GPT support

Con mia piacevole sorpresa ho scoperto che l’HP MicroServer, pur non avendo EFI, supporta il boot da dischi partizionati con struttura GPT invece che MBR. Con Fedora 14 è stato sufficiente preparare i dischi formattati con gdisk; anaconda, l’installer, li riconosce correttamente; è quindi possibile utilizzare il disco.

I vantaggi di GPT sono molti, a partire dall’assenza di problemi di allineamento (soprattutto con dischi a settori di 4k) passando per il supporto a più di 4 partizioni primarie.

Riferimenti

https://wiki.archlinux.org/index.php/Advanced_Format