# rm-rf.es | Administración de sistemas

Bitácora personal de un SysAdmin Gnu/Linux, Windows, BSD...

Hacer cambios en un filesystem GFS2 con gfs2_tool y gfs2_edit

Como muchos ya sabéis, cuando creamos un sistema de ficheros GFS2 especificamos entre otras cosas el nombre del Cluster al que va asociado, un nombre para el sistema de ficheros, el número de Journals, las tablas de bloqueo, etc. Si por lo que sea necesitamos cambiar a posteriori uno de estos parámetros podemos hacerlo con el comando gfs2_tool y gfs2_edit.

Pongámonos en situación. Hemos creado el siguiente sistema de ficheros GFS2:

# mkfs.gfs2 -p lock_dlm -t cluster01:fs_data -j 2 /dev/vgroup01/logical01

En mi caso, únicamente tenía que modificar el nombre asignado al filesystem, para ello se ejecuta el siguiente comando, siempre con el filesystem desmontado en todos los nodos del Cluster

# gfs2_tool sb /dev/vgroup01/logical01 table nuevo-cluster:nuevo-nombre-fs

Veis como cambiamos el nombre del cluster y del filesystem. Si ejecutáis los comandos sin parámetros veréis más opciones y ejemplos:

# gfs2_tool 
Clear a flag on a inode
  gfs2_tool clearflag flag 
Freeze a GFS2 cluster:
  gfs2_tool freeze 
Get tuneable parameters for a filesystem
  gfs2_tool gettune 
List the file system's journals:
  gfs2_tool journals 
Have GFS2 dump its lock state:
  gfs2_tool lockdump  [buffersize]
Tune a GFS2 superblock
  gfs2_tool sb  proto [newval]
  gfs2_tool sb  table [newval]
  gfs2_tool sb  ondisk [newval]
  gfs2_tool sb  multihost [newval]
  gfs2_tool sb  all
Set a flag on a inode
  gfs2_tool setflag flag 
Tune a running filesystem
  gfs2_tool settune   
Unfreeze a GFS2 cluster:
  gfs2_tool unfreeze 
Print tool version information
  gfs2_tool version
Withdraw this machine from participating in a filesystem:
  gfs2_tool withdraw
# gfs2_edit
...
...
   To run in interactive mode:
     gfs2_edit /dev/bobs_vg/lvol0
   To print out the superblock and master directory:
     gfs2_edit -p sb master /dev/bobs_vg/lvol0
   To print out the master directory in hex:
     gfs2_edit -x -p master /dev/bobs_vg/lvol0
   To print out the block-type for block 0x27381:
     gfs2_edit identify -p 0x27381 /dev/bobs_vg/lvol0
   To print out the fourth Resource Group. (the first R is #0)
     gfs2_edit -p rg 3 /dev/sdb1
   To print out the metadata type of block 1234
     gfs2_edit -p 1234 blocktype /dev/roth_vg/roth_lb
   To print out the allocation type of block 2345
     gfs2_edit -p 2345 blockalloc /dev/vg/lv
   To change the allocation type of block 2345 to a 'free block'
     gfs2_edit -p 2345 blockalloc 0 /dev/vg/lv
   To print out the file size of the dinode at block 0x118
     gfs2_edit -p 0x118 field di_size /dev/roth_vg/roth_lb
   To find any dinode higher than the quota file dinode:
     gfs2_edit -p quota find di /dev/x/y
   To set the Resource Group flags for rg #7 to 3.
     gfs2_edit rgflags 7 3 /dev/sdc2
   To save off all metadata for /dev/vg/lv without compression:
     gfs2_edit savemeta -z 0 /dev/vg/lv /tmp/metasave

Clustered Logical Volume Manager (CLVM) y GFS2

En esta entrada vamos a ver el proceso de instalación y configuración de CLVM y la forma de crear un sistema de ficheros GFS2. Se podría decir que esta entrada sería la continuación de aquella en la que expliqué el Multipath en Linux. Básicamente, la idea es utilizar CLVM para aprovecharnos de las ventajas de LVM (Logical Volume Manager) en un entorno de Cluster.

Como estamos trabajando en un cluster, voy a diferenciar cuando una tarea se realiza en un único nodo o en todos. Los paquetes de cluster LVM y GFS los instalaremos en todos los nodos del cluster:

# yum install lvm2-cluster.x86_64 gfs2-utils.x86_64

Posteriormente nos aseguramos de que arranquen automáticamente:

# chkconfig clvmd on
# chkconfig gfs2 on

Con la configuración por defecto, LVM no trabaja en modo Cluster, incluso aunque hayamos instalado los paquetes de clvmd o lo hayamos arrancado, debemos reconfigurarlo con el siguiente comando. Lo que hace es modificar el fichero de configuración lvm.conf y especificar el tipo de bloqueo necesario para trabajar en cluster (cluster-wide locking).

# /usr/sbin/lvmconf --enable-cluster

Arrancamos el servicio clvmd:

# service clvmd start

A partir de aquí, el proceso de gestión de volumenes es el mismo que con LVM. Revisad este otro artículo si tenéis alguna duda: gestión de LVM en Linux (Logical Volume Manager). Vamos no obstante a ver como crearíamos una nueva partición con parted en lugar de fdisk como en el otro artículo. En este caso es un disco en multipath, por eso la ruta del mapeo. Esto lo realizamos únicamente en uno de los nodos:

# parted /dev/mapper/mpatha mklabel msdos
# parted /dev/mapper/mpatha mkpart primary 64s 100%
# parted /dev/mapper/mpatha set 1 lvm on

En ese mismo nodo ya podemos crear el volumen físico y el grupo que contendrá el volumen lógico con la partición creada antes:

# pvcreate /dev/mapper/mpathap1
# vgcreate vgroup01 /dev/mapper/mpathap1

Antes de crear el volumen, podemos ir al resto de nodos y asegurarnos que ven la nueva partición y el volumen físico y grupo. Ejecutamos partprobe para refrescar la tabla de particiones en la unidad multipath y luego un rescaneo de los volúmenes de LVM:

# partprobe
# vgscan

Debería aparecer el volumen vgroup01 al ejecutar un vgdisplay, sino algo falla y CLVMD no está funcionando ya que no se propagan los cambios entre los nodos del cluster. Si todo ha ido bien, ya podemos crear (sólo en un nodo) el volumen lógico final y crear el sistema de ficheros GFS2:

# lvcreate -n logical01 -l 77063 vgroup01
# mkfs.gfs2 -p lock_dlm -t cluster01:fs_data -j 2 /dev/vgroup01/logical01

A la hora de crear el sistema de ficheros, especificamos el nombre del protocolo de bloqueo a usar, para un cluster es lock_dlm. Después se indica el nombre del cluster y  del filesystem separados por “:”, en nuestro caso el cluster (RHCS) se llama cluster01 y el fs fs_data. Tenemos que especificar el número de journals que queremos crear, tiene que haber uno por cada nodo del cluster. En este caso 2 nodos así que ponemos 2. Lo último es la ruta al volumen lógico o partición a utilizar.

A partir de aquí ya depende si queréis añadir el filesystem para que se monte automáticamente al arrancar los nodos (/etc/fstab/) o si será el cluster el encargado de gestionarlo.

Configurar Multipath I/O (MPIO) en Windows 2008 Server

El otro día vimos como activar Multipath en Linux (RedHat y derivados). Ahora vamos a ver como hacerlo en Windows 2008 Server. Resulta muy sencillo, ya que únicamente hay que activar la característica “Multipath I/O” y hacer una búsqueda de los caminos.

Añadir soporte Multipath I/O MPIO

Abrimos el Server Manager (Administrative Tools > Server Manager) y pinchamos en añadir características (Add Features) dentro de la sección Features. En el asistente, seleccionamos Multipath I/O e instalamos.

Configurar los caminos

Antes de activar Multipath, si accedemos al gestor de storage/discos en el Server Manager veremos que cada camino es detectado como un disco. Lo que nos interesa es que detecte únicamente el disco real y que por debajo gestione todos los caminos. Ahora que hemos instalado la característica, accedemos a MPIO Properties desde el panel de control o desde MPIO en Administrative Tools del menú Inicio.

Ahora, para descubrir las LUN FC debería ser suficiente con ir a la pestaña “Discover Multi-Path” y pinchar en “Add”. Solicitará un reinicio del sistema y una vez realizado los caminos y discos debería haber sido detectados.

Nota: en esta imagen ya han sido detectadas, por eso no sale disponible el botón.

Multipath Windows 2008 Server

Podéis verificar la configuración de cada mapeo con la herramienta mpclaim.exe:

PS C:\Users\Administrator> mpclaim.exe -s -d 0

MPIO Disk0: 04 Paths, Round Robin with Subset, Implicit Only
   Controlling DSM: Microsoft DSM
   SN: 60A9800572D4275525A6939686A5063
   Supported Load Balance Policies: FOO RRWS LQD WP LB

   Path ID          State              SCSI Address      Weight
   ---------------------------------------------------------------------------
   0000000077020001 Active/Unoptimized 002|000|001|000   0
     TPG_State : Active/Unoptimized, TPG_Id: 1, : 1

   0000000077020000 Active/Optimized   002|000|000|000   0
     TPG_State : Active/Optimized  , TPG_Id: 0, : 257

   0000000077010001 Active/Unoptimized 001|000|001|000   0
     TPG_State : Active/Unoptimized, TPG_Id: 1, : 2

   0000000077010000 Active/Optimized   001|000|000|000   0
     TPG_State : Active/Optimized  , TPG_Id: 0, : 258

El último número hace referencia al mapeo/disco que queremos revisar,

DM-Multipath en RedHat y CentOS

Hoy vamos a ver una introducción y la forma de activar Multipath en RedHat y derivados (CentOS, Scientific Linux…). Si todo va bien, y la cabina que nos sirve los discos está soportada por defecto por DM-Multipath es probable que no necesitemos apenas configuraciones manuales. Básicamente, el multipath lo que hace es ofrecer tolerancia a fallos y alta disponibilidad, ofreciendo más de un camino entre el sistema y los discos servidos por una SAN. Por ejemplo, cuando la conexión se hace a través de dos o más puertos Fiber Channel o cuando un disco SCSI está conectado a dos controladoras distintas.

Instalación y configuración inicial de DM-Multipath

Lo primero realizamos la instalación a través de yum:

# yum install device-mapper-multipath

Activamos su inicio automático:

# chkconfig multipathd on

mpathconf nos permite realizar una primera configuración del servicio, creando el fichero de configuración, ya sea con los valores por defecto o especificando unas directivas concretas. Para crear una configuración estándar:

# mpathconf --enable

Este otro ejemplo arrancaría dm-multipath con una configuración de failover estándar y activa el fichero de configuración:

# mpathconf --enable --with_multipathd y

Revisad la página man de mpathconf para más información. Posteriormente ya deberíamos tener el demonio de multipath. Para arrancar, parar y demás podéis usar el script de init.d como cualquier otro servicio.

# ps aux | grep multipath
root     17284  1.0  0.0 493756  4432 ?        SLl  04:24   0:00 /sbin/multipathd

Algo importante a tener en cuenta es la necesidad de incluir como “blacklist” los discos locales en el fichero de configuración. Si por ejemplo son los sdaX añadimos “sda” a la sección blacklist. De este modo multipath ignorará estos discos y no buscará más de un camino para ellos:

blacklist {
       wwid 26353900f02796769
	devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|sda|st)[0-9]*"
	devnode "^hd[a-z]"
}

El fichero de configuración es lo suficientemente descriptivo para que podáis revisar cada una de las opciones.

Administración y monitorización de DM-Multipath

Si las LUN o discos que queremos tener en multipath se ven con un fdisk, el mapeo debería haberse configurado automáticamente como /dev/mapper/mpathb, /dev/mapper/mpathc…, sino, antes hay que revisar porqué el sistema no visualiza los discos. Si no se trata de controladoras o cabinas conocidas o soportadas, es probable que haya que realizar alguna configuración manual, en la mayoría de los casos el mapping debería ser automático.

La mejor forma de ver el estado del multipath es entrando en la “shell” de multipath, lo hacemos del siguiente modo:

# multipathd -k
multipathd>

Una vez dentro, algunos de los comandos más útiles son los siguientes:

Ver el estado de los path:

multipathd> show multipaths status
name   failback  queueing paths dm-st  write_prot
mpathb immediate -        4     active rw

Ver todos los multipath disponibles y mappings. En este caso hay dos mappings, cada uno con cuatro caminos:

multipathd> show multipaths
name   sysfs uuid
mpathb dm-0  360a98000572d4275525a693862534571
mpathc dm-1  360a98000572d4275525a693875677278
multipathd> show maps
name   sysfs uuid
mpathb dm-0  360a98000572d4275525a693862534571
mpathc dm-1  360a98000572d4275525a693875677278

Ver todos los path:

multipathd> show paths
hcil    dev dev_t pri dm_st  chk_st dev_st  next_check
1:0:0:0 sdb 8:16  4   active ready  running XXXXXXXXXX 20/20
1:0:0:1 sdc 8:32  4   active ready  running XXXXXXXXXX 20/20
2:0:0:0 sdd 8:48  4   active ready  running XXXXXXXXX. 19/20
2:0:0:1 sde 8:64  4   active ready  running .......... 1/20
2:0:1:0 sdf 8:80  1   active ready  running XXXXXXXXX. 18/20
2:0:1:1 sdg 8:96  1   active ready  running XXXXXXXXXX 20/20
1:0:1:0 sdh 8:112 1   active ready  running XXXXXXXXX. 18/20
1:0:1:1 sdi 8:128 1   active ready  running XXXXXXXXX. 19/20

Ver la topología y políticas configuradas para cada multipath. En este caso vemos dos LUN de fibra de 300G servidas por una cabina de discos NetAPP, con política round-robin 0 y todos sus path activos:

multipathd>  show topology
mpathb (360a98000572d4275525a693862534571) dm-0 NETAPP,LUN
size=301G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=4 status=active
| |- 1:0:0:0 sdb 8:16  active ready running
| `- 2:0:0:0 sdd 8:48  active ready running
`-+- policy='round-robin 0' prio=1 status=enabled
  |- 2:0:1:0 sdf 8:80  active ready running
  `- 1:0:1:0 sdh 8:112 active ready running
mpathc (360a98000572d4275525a693875677278) dm-1 NETAPP,LUN
size=301G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=4 status=active
| |- 1:0:0:1 sdc 8:32  active ready running
| `- 2:0:0:1 sde 8:64  active ready running
`-+- policy='round-robin 0' prio=1 status=enabled
  |- 2:0:1:1 sdg 8:96  active ready running
  `- 1:0:1:1 sdi 8:128 active ready running

Si escribís help dentro de esta shell veréis todos los comandos disponibles, podemos gestionar completamente el multipath desde aquí. Podemos suspender un camino, ponerlo en estado ‘fail’, eliminarlo, etc:

multipathd> help
multipath-tools v0.4.9 (04/04, 2009)
CLI commands reference:
 list|show paths
 list|show paths format $format
 list|show status
 list|show daemon
 list|show maps|multipaths
 list|show maps|multipaths status
 list|show maps|multipaths stats
 list|show maps|multipaths format $format
 list|show maps|multipaths topology
 list|show topology
 list|show map|multipath $map topology
 list|show config
 list|show blacklist
 list|show devices
 list|show wildcards
 add path $path
 remove|del path $path
 add map|multipath $map
 remove|del map|multipath $map
 switch|switchgroup map|multipath $map group $group
 reconfigure
 suspend map|multipath $map
 resume map|multipath $map
 resize map|multipath $map
 disablequeueing map|multipath $map
 restorequeueing map|multipath $map
 disablequeueing maps|multipaths
 restorequeueing maps|multipaths
 reinstate path $path
 fail path $path
 paths count
 quit|exit

Esto ha sido una mera introducción, para profundizar en el tema, os recomiendo la lectura de los siguientes artículos. Próximamente veremos como configurar desde 0 una LUN FC servida NetAPP en Multipath y asignarle un filesystem.

Netapp Snapmirror entre dos cabinas

NetAppHacía ya un tiempo que no hacia entradas sobre Netapp, así que vamos a retomar un poco el tema con la utilidad Snapmirror, que permite replicar volumenes/qtrees entre filers. Snapmirror va a trabajar de forma sincrona (snapmirror_sync) y replicando los datos contra el volumen de respaldo a la vez que se escriben en el volumen original o por contra especificando una periodicidad concreta al más puro estilo cron. Los datos antes de ser escritos en disco se guardan en NVRAM con el fin de asegurar su consistencia.

Lo primero de todo, lógicamente es disponer la licencia de snapmirror en ambas cabinas, en este caso vamos a trabajar sobre netapp01 (192.168.1.100) y netapp02 (192.168.1.129). Activamos la licencia y posteriormente snapmirror:

Activación de Snapmirror

Para realizar en los dos filer:

NetApp01> license add XXXXXX
A snapmirror site license has been installed.
snapmirror enabled.
NetApp01> Sat Dec  3 20:02:32 GMT [rc:notice]: snapmirror licensed

NetApp01> license add XXXXXX
A snapmirror_sync site license has been installed.
Sync SnapMirror enabled.

NetApp01> options snapmirror.enable on
NetApp01> options snapmirror.log.enable on

Conectividad entre filers

Lo primero que debemos hacer es revisar la conectividad entre ambas cabinas:

NetApp01> ping 192.168.1.129
192.168.1.129 is alive

NetApp02> ping 192.168.1.100
192.168.1.100 is alive

Configuramos el filer origen permitiendo que el filer destino pueda acceder a él, para ello hay que añadir el hostname/ip del filer destino en el fichero /etc/snapmirror.allow. Antes de nada verificad si existe y tiene contenido para preservarlo, ya que con wrfile eliminamos lo que hubiera anteriormente:

NetApp01> rdfile /etc/snapmirror.allow
/etc/snapmirror.allow: No such file or directory

NetApp01> rdfile /etc/snapmirror.allow
/etc/snapmirror.allow: No such file or directory
NetApp01> wrfile /etc/snapmirror.allow
192.168.1.129
NetApp02
CTRL + C
read: error reading standard input: Interrupted system call
NetApp01> rdfile /etc/snapmirror.allow
192.168.1.129

Creación de volúmenes a replicar

Vamos a crear el volumen de datos en el filer origen:

NetApp01> vol create vol_backup aggr_test 200M
Creation of volume 'vol_backup' with size 200m on containing aggregate
'aggr_test' has completed.

Snapmirror

Una vez creado el volumen en el filer origen, ya podemos crear la configuración de Snapmirror en el destino. Algunas consideraciones son que para hacer Snapmirror el volumen destino tiene que estar en modo restricted. De este modo únicamente permitimos ciertas operaciones en el volumen, como snapmirror o tareas de mantenimiento, pero nunca el acceso a los datos:

Creamos el volumen:

NetApp02> vol create vol_mirror aggr0 200M
Creation of volume 'vol_mirror' with size 200m on containing aggregate
'aggr0' has completed.

Lo restringimos para poder hacer la transferencia inicial:

NetApp02> vol restrict vol_mirror
Volume 'vol_mirror' is now restricted.

Ejecutamos la transferencia inicial de datos:

NetApp02> snapmirror initialize -S 192.168.1.100:vol_backup NetApp02:vol_mirror
Transfer started.
Monitor progress with 'snapmirror status' or the snapmirror log.

Podemos ver el estado mediante snapmirror status o a través del log específico (en caso de haber sido activado como mencionaba antes):

NetApp02> snapmirror status
Snapmirror is on.
Source                    Destination           State          Lag        Status
192.168.1.100:vol_backup  NetApp02:vol_mirror   Snapmirrored   00:00:15   Idle

Configurar periodicidad de sincronización

Una vez realizada la copia inicial, podemos programar las copias incrementales cada X tiempo o que se realicen de forma síncrona. En estas copias únicamente se transferirán los bloques que hayan sido modificados desde la última realizada. Estas configuraciones se especifican en el fichero de configuración /etc/snapmirror.conf con esta estructura:

filer_origen:volumen_origen filer_destino:volumen_destino – opciones min hora dia_mes dia_sem

Para configurar que la copia sea síncrona y que los datos se mantengan actualizados al mismo tiempo en ambos volúmenes únicamente hay que añadir la palabra sync (recordad revisar antes el contenido del fichero):

NetApp02> wrfile /etc/snapmirror.conf
192.168.1.100:vol_backup NetApp02:vol_mirror - sync
CTRL+C

Nota: para la replicación síncrona el volumen tiene que tener un tamaño mínimo, sino recibiréis este error:

Sun Dec 4 08:38:00 GMT [snapmirror.src.sync.FvolSyncTooSmall:error]: The flexible volume Synchronous SnapMirror source vol_backup is 200 MB, which is smaller than the minimum supported size of 10240 MB.

Y si lo que queremos es que la sincronización se realice periódicamente en lugar de a tiempo real usamos el estilo cron que veíamos en la estructura. Vamos a configurarlo todos los días a las 23:00:

NetApp02> wrfile /etc/snapmirror.conf
192.168.1.100:vol_backup NetApp02:vol_mirror - 00 23 * *
CTRL+C

Es recomendable cuando hacemos la configuración de snapmirror y las primeras sincronizaciones tener las consolas de ambas cabinas abiertas para revisar todos los errores que puedan ir apareciendo en una y otra.

Si necesitaramos forzar manualmente la sincronización podemos hacerlo con el comando snapmirror update, con la misma sintaxis que utilizamos con la sincronización inicial:

NetApp02> snapmirror update -S 192.168.1.100:vol_backup NetApp02:vol_mirror
Transfer started.
Monitor progress with 'snapmirror status' or the snapmirror log.

Podéis revisar otros comandos como snapmirror abort para cancelar la sincronización, snapmirror break, snapmirror resync, etc.

Gestión de particiones con parted en Linux

gnu partedHace un tiempo aprendimos a gestionar discos y particiones con fdisk, ahora vamos ver como trabajar con el programa GNU parted, que permite particionar y redimensionar discos, así como crear, redimensionar y copiar sistemas de fichero extX, swap, FAT y FAT32 (luego veremos que es recomendable utilizar las herramientas propias de Linux en lugar que las que ofrece parted en algunos casos).

Vamos a partir de un disco (virtual) sin particionar. Lo primero que vemos al acceder a parted es un error, ya que parted necesita que el disco tenga una etiqueta (LABEL) para poder trabajar con él:

# parted /dev/sdb
GNU Parted 2.1
Usando /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print                                                            
Error: /dev/sdb: unrecognised disk label

Normalmente se utiliza la etiqueta ‘msdos’ ya que Microsoft y OS/2 es la que reconocen, así que la asignamos con el comando mklabel:

(parted) mklabel                                                          
¿Nuevo tipo de etiqueta de disco? msdos

En todo momento podéis ver los comandos disponibles escribiendo el signo de interrogación (?)

(parted) ?                                                                
  align-check TYPE N                        check partition N for TYPE(min|opt) alignment
  check NUMBER                             do a simple check on the file system
  cp [DESDE-DISPOSITIVO] DE-NUMERO A-NUMERO   copia el sistema de ficheros a otra partición
  help [COMMAND]                           print general help, or help on COMMAND
  mklabel,mktable LABEL-TYPE               create a new disklabel (partition table)
  mkfs NUMBER FS-TYPE                      make a FS-TYPE file system on partition NUMBER
  mkpart TIPO-PART [TIPO-SF] INICIO FIN     crea una partición
  mkpartfs TIPO-PART TIPO-SF INICIO FIN     crear una partición con un sistema de ficheros
...
...
...

print: listar discos duros, particiones y espacio libre

El comando print nos permite por un lado mostrar todos los dispositivos (discos duros) reconocidos por el sistema:

(parted) print devices                                                    
/dev/sdb (268MB)
/dev/sda (12,7GB)

También las particiones de cada uno y/o el espacio libre:

(parted) print free                                                       
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sdb: 268MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Numero  Inicio  Fin    Tamaño  Typo  Sistema de ficheros  Banderas
        32,3kB  268MB  268MB         Free Space

mkpart: crear una partición sin filesystem

Parted nos da la opción de crear una partición y al mismo tiempo el sistema de ficheros (lo vemos más adelante), pero de momento únicamente vamos a crear una partición estándar sin asignar filesystem. Podemos hacer dos cosas, o seguir el asistente o escribir la línea de comandos completa directamente. Para comenzar lo más sencillo es el asistente:

Partición primaria de 100MB que será usada como filesystem ext4

(parted) mkpart
¿Tipo de partición?  primary/primaria/extended/extendida? primary         
¿Tipo de sistema de ficheros?  [ext2]? ext4                               
¿Inicio? 1                                                                
¿Fin? 100

Si ejecutamos un print list veremos la nueva partición lista para ser formateada con mkfs.ext4:

(parted) print                                                            
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sdb: 268MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Numero  Inicio  Fin     Tamaño  Typo     Sistema de ficheros  Banderas
 1      1049kB  99,6MB  98,6MB  primary

mkpartfs: crear una partición con filesystem

Como comentaba antes, parted permite dar formato a la partición en el proceso de creación, aunque claramente vemos al ejecutarlo que recomiendan encarecidamente hacer uso de las herramientas adecuadas para ello (mkfs.extX, e2fsprogs). Así que simplemente vamos a ver como hacerlo por curiosidad (además no soporta ni ext3 ni ext4, sólo ext2…):

WARNING: you are attempting to use parted to operate on (mkpartfs) a file system.
parted’s file system manipulation code is not as robust as what you’ll find in
dedicated, file-system-specific packages like e2fsprogs. We recommend
you use parted only to manipulate partition tables, whenever possible.
Support for performing most operations on most types of file systems
will be removed in an upcoming release.

(parted) mkpartfs                                                         
WARNING: you are att.....
will be removed in an upcoming release.
¿Tipo de partición?  primary/primaria/extended/extendida? primary         
¿Tipo de sistema de ficheros?  [ext2]? ext2                               
¿Inicio? 100                                                              
¿Fin? 200

Y ya tenemos la partición con sistema de ficheros ext2:

(parted) print                                                            
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sdb: 268MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Numero  Inicio  Fin     Tamaño  Typo     Sistema de ficheros  Banderas
 1      1049kB  99,6MB  98,6MB  primary
 2      99,6MB  200MB   101MB   primary  ext2
# mount /dev/sdb2 /test
# df -h | grep /test
/dev/sdb2              90M   13K   86M   1% /test
# umount /test

rm: eliminar una partición

Para eliminar una partición con parted es tan simple como ejecutar “rm” seguido del número de la partición:

(parted) print                                                            
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sdb: 268MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Numero  Inicio  Fin     Tamaño  Typo     Sistema de ficheros  Banderas
 1      1049kB  99,6MB  98,6MB  primary
 2      99,6MB  200MB   101MB   primary  ext2
(parted) rm 2  /pre>

check: comprobación de un filesystem

Existen otras opciones, como por ejemplo hacer un check al sistema de ficheros, pero igual que con mkpartfs recomiendan utilizar herramientas propias del sistema como fsck. Además, no soportan sistemas de ficheros ext4 o ext3:

(parted) check 1                                                          
WARNING: you are attempting to use parted to operate on (check) a file system.
parted's file system manipulation code is not as robust as what you'll find in
dedicated, file-system-specific packages like e2fsprogs.  We recommend
you use parted only to manipulate partition tables, whenever possible.
Support for performing most operations on most types of file systems
will be removed in an upcoming release.
Sin Implementación: El soporte para abrir el sistema de ficheros ext4 aún no está implementado.


Si revisáis la página man o la propia salida de ‘?’ veréis otras opciones, como mkfs para formatear sistemas de ficheros (como comentaba antes, no recomendable) y otras más interesantes como rescue, que permite recuperar una partición perdida indicando su posición de inicio y fin:

(parted) rescue INICIO FIN

Os recomiendo como siempre revisar la página man o la salida de ‘?’ para descubrir todas sus posibilidades, como redimensionar una partición con resize, moverla con move, etc. Eso sí, recordad que es preferible usar los comandos/herramientas propios del sistema para mayor seguridad en estos casos.

Montar un filesystem por UUID o label

disco duroEl beneficio de montar los sistemas de ficheros con su UUID o label en lugar de con el nombre asignado a la partición (/dev/sda1, /dev/hda2…) es que se trata de un identificador único, como su propio nombre indica: Universally Unique Identifier (UUID). Esto evita problemas que se pueden producir cuando añadimos nuevos dispositivos al sistema, movemos particiones, etc ya que el nombre de la partición puede cambiar pero no el UUID o label (etiqueta asignada por nosotros).

¿Cómo averiguamos el UUID de una partición?

Hay varias formas: con el comando blkid, tune2fs… Vamos a localizar el UUID de la partición /dev/sda2:

# tune2fs -l /dev/sda2 | grep UUID
Filesystem UUID:          528c141b-66fd-43d5-808b-4a94a639f323
# blkid /dev/sda2
/dev/sda2: UUID="528c141b-66fd-43d5-808b-4a94a639f323" TYPE="ext4"

Con esta información ya podemos añadir la entrada correspondiente al fichero /etc/fstab. Si antes estaba así:

/dev/sda2     /datos               ext4    defaults        1 1

Ahora quedaría así:

UUID=528c141b-66fd-43d5-808b-4a94a639f323     /datos        ext4    defaults   1 1

¿Y cómo averiguamos o configuramos la etiqueta del filesystem?

Es sencillo, con el comando tune2fs seguido del parámetro -L podemos configurar la etiqueta que queramos:

# tune2fs -L "DATOS" /dev/sda2
tune2fs 1.41.12 (17-May-2010)

Para consultar la etiqueta/label de la partición:

# tune2fs -l /dev/sda2 | grep "Filesystem volume name"
Filesystem volume name:   DATOS

También podemos verla con el comando anterior blkid, ahora que la partición tiene label nos muestra tanto el UUID como la etiqueta:

# blkid /dev/sda2
/dev/sda2: UUID="528c141b-66fd-43d5-808b-4a94a639f323" TYPE="ext4" LABEL="DATOS"

Y para montarla en /etc/fstab tan sencillo como:

LABEL=DATOS     /datos        ext4    defaults   1 1

Autofs y automount para servir nfs

Algunos de los pros de automount/autofs frente a montar sistemas de ficheros de forma estática es su dinamismo y simplicidad. Si utilizamos automount para servir nfs podemos conseguir que el export NFS únicamente esté montado cuando realmente es necesario, reduciendo la posibilidad de corrupción del sistema de ficheros. Si es un filesystem con pocos accesos también es útil no tenerlo montado de forma permanente y establecer un timeout.

En la parte práctica, nfs con automount es muy útil para servir las /home de usuarios, pudiendo el usuario tener un mismo directorio home centralizado para varias máquinas, también para repositorios de software compartido, etc. Vamos a ver el ejemplo más sencillo de servir un directorio por nfs y automount en unas máquinas CentOS:

Requisitos

Necesitaremos estos dos paquetes:

# yum install nfs-utils autofs

Disponer de una NAS o servidor NFS con un export configurado (IP 192.168.1.144), por ejemplo:

# more /etc/exports
/repo *(rw)

Configuración automount en los clientes

El fichero de configuración principal es /etc/auto.master, en el cual se especifican los mapeos, puntos de montaje y parámetros de configuración. Muchas veces, por limpieza y tener mejor estructuración, los parámetros y puntos de montaje se especifican en ficheros aparte (/etc/auto.misc o el que queramos).

Nosotros queremos por un lado, mapear el directorio local /export con el sistema de ficheros NFS. De momento establecemos esta configuración en auto.master (Tenéis ejemplos en el fichero así como comentarios de ayuda):

/export        /etc/auto_repo

Y en el fichero /etc/auto_repo especificamos punto de montaje, flags del filesystem y el export NFS:

repo	-fstype=nfs,rw,nosuid	192.168.1.144:/repo

Iniciamos servicios autofs y nfs:

/etc/init.d/nfs start && /etc/init.d/autofs start

Vemos los puntos de montaje actuales:

# df -h
S.ficheros            Size  Used Avail Use% Montado en
/dev/sda2             7,7G  970M  6,4G  13% /
tmpfs                 376M     0  376M   0% /dev/shm
/dev/sda1             485M   28M  432M   7% /boot
/dev/sda5            1008M   34M  924M   4% /home

Entramos en /export/repo y volvemos a revisar los puntos de montaje, aparece automáticamente el export NFS:

Nota: con automount tienes que saber el path directo, no puedes usar [TAB]

# cd /export/repo
[root@server1 repo]# df -h
S.ficheros            Size  Used Avail Use% Montado en
/dev/sda2             7,7G  970M  6,4G  13% /
tmpfs                 376M     0  376M   0% /dev/shm
/dev/sda1             485M   28M  432M   7% /boot
192.168.1.144:/repo   7,7G  963M  6,4G  13% /export/repo

Una vez pasado el timeout especificado el punto de montaje quedaría desmontado automáticamente. Este es el ejemplo más básico de automount y autofs, podríamos llegar a montar vía export todas las home de usuario, Autofs + LDAP y otras configuraciones más complejas. De momento esta es la idea básica sobre la que podéis comenzar a trabajar. Os dejo unos enlaces recomendados para aprender más sobre autofs:

  1. Automount y autofs en es.tldp.org
  2. Automounter examples en www.linux-consulting.com
Ver el perfil de Alejandro García García en LinkedIn