Ir al contenido principal

Can't open /dev/mapper/ exclusively - not removing. Mounted filesystem?

Por elevado/distraido presente dos discos desde la SAN (para mi caso un IBM StoreWize 7000) de 20Gb cada uno cuando realmente debía ser solo de 2Gb, a un par de servidores Linux que van destinados para montar Oracle RAC; es decir, me sobre en el espacio asignado.

Como estos discos ya habían sido pasados por el fdisk y mapeados en ambas máquinas no me funciona el hecho de solo reducir el tamaño desde el almacenamiento ya que el fdisk le dice al sistema dónde inicia y termina cada uno los sectores de los discos en cuestión.

Se podría pensar... mmm entonces un pvresize, y de hecho pvresize nos permite "reducir" el tamaño del disco "a nivel de sistema operativo" actualizando los sectores con la siguiente instrucción:


#pvresize --setphysicalvolumesize 2G /dev/mapper/disco1
#pvresize --setphysicalvolumesize 2G /dev/mapper/disco2

Y los discos quedan "a nivel de sistema operativo" de 2G; pero si consultas el almacenamiento sigues viendo los dos discos de... 20Gb cada uno y el objetivo es recuperar esas 18Gb (bueno 36Gb si sumamos los dos discos) que luego podemos utilizar para otras cosas.

Se intentó con el comando pvremove pero me arrojaba el mensaje:

Can't open /dev/mapper/ exclusively - not removing. Mounted filesystem?

Por más que lo intentaba no lograba removerlo hasta que intené con otros comandos.

Hice un fdisk del disco para ver toda su información a nivel de sectores, heads, etc  y note que me aparecía otra ruta mapeada asociada al disco principal.  Ejemplo:

#fdisk /dev/mapper/mpathb

WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
         switch off the mode (command 'c') and change display units to
         sectors (command 'u').

Orden (m para obtener ayuda): p

Disco /dev/mapper/mpathb: 21.5 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders
Units = cilindros of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x3cd70bd4

          Disposit. Inicio    Comienzo      Fin      Bloques  Id  Sistema
/dev/mapper/mpathbp1               1        2610    20964793+  8e  Linux LVM

mmm, entonces pensé que quizás esta era la razón por la que no se dejaba remover el disco así que trate de eliminar primero este dispositivo con (inocentemente) con el pvremove, pero me apareció el siguiente mensaje del sistema operativo burlándose de mi:

#pvremove /dev/mapper/mpathbp1

No physical volume label read from /dev/mapper/mpathbp1
  Physical Volume /dev/mapper/mpathbp1 not found

Entonces recorde el comando dmsetup que tiene que ver con el mapeador de dispositivos y que tiene un parámetro para remover así que...

#dmsetup remove /dev/mapper/mpathbp1
#dmsetup remove /dev/mapper/mpathb
#pvdisplay /dev/mapper/mpathb
Failed to read physical volume "/dev/mapper/mpathb"

Eureka.  Solucionado; ya no existe el disco.  Ahora si puedo generar los discos con el tamaño adecuado y presentarlos nuevamente a los servidores.

En mi caso, cuando fui a validar en el otro nodo si ya había desaparecido del listado de los pv el disco se quedo pegado al ejecutar el comando:

#pvdisplay

No me dio más de otra que reiniciar la máquina desde el manager y esperar a que volviera a la vida.  Debe haber algún procedimiento por pulir y creería que es el borrar el /dev/mapper/mpathbp1 desde dicho nodo y luego el otro desde el nodo contrario.

Queda ese tema por validar, aunque confieso que no he mirado los logs del sistema para que me cuenten qué sucedió pero de que me funcionó, me funcionó!

Comentarios

Entradas populares de este blog

Lenguajes de programación más conocidos en la historia de la computación

Los primeros lenguajes de programación eran difíciles de construir ya que éstos debían ser "desarrollados" a un nivel que la máquina entendiera directamente, es decir, la programación de computadoras de esta época dependía mucho de la máquina para la que se estaba trabajando y detectar un error o fallo en la programación no solo era complejo sino que demandaba mucho tiempo y esfuerzo. En 1946 Grace Murray Hopper, científica en sistemas y oficial de la marina estadounidense creo el FLOW-MATIC, considerado el primer lenguaje de programación útil para resolver problemas de usuarios comerciales.  Su desarrollo fue enfocado a la UNIVAC 1.  Este lenguaje de programación fue visto como de "alto nivel", fácil de usar por los científicos de la época.  FLOW-MATIC requería de un traductor (compilador) para ser interpretado por la máquina.   Con este lenguaje de programación se establece el concepto de programación basado en palabras del lenguaje natural y se da inicio al d...

Las 10 Aplicaciones Más Descargadas en Google Play Store y Apple App Store en 2024

  En el mundo digital actual, las aplicaciones móviles juegan un papel crucial en nuestras vidas diarias. Con millones de aplicaciones disponibles, solo unas pocas logran destacar y acumular millones de descargas. En este artículo, exploramos las aplicaciones más descargadas en Google Play Store y Apple App Store hasta la primera mitad de 2024. 1. Instagram Instagram sigue siendo una de las aplicaciones más populares a nivel mundial. Con 696 millones de descargas en Google Play Store, esta plataforma de redes sociales permite a los usuarios compartir fotos y videos, interactuar con amigos y seguir a celebridades. 2. TikTok TikTok, la aplicación de videos cortos, ha revolucionado la forma en que consumimos contenido. Con 654 millones de descargas en Google Play Store, se mantiene como una de las favoritas entre los usuarios jóvenes y creativos. 3. Facebook Facebook, la red social pionera, continúa siendo relevante con 553 millones de descargas . La plataforma ofrece una variedad d...

SQL Error [53200]: ERROR: out of shared memory

  ¡Hola, amigos del blog! Hoy vamos a hablar sobre un tema que puede causar más de un dolor de cabeza a los que trabajamos con PostgreSQL: el temido error SQL Error [53200]: ERROR: out of shared memory. Pero no te preocupes, porque aquí te explico por qué sucede y cómo solucionarlo de manera sencilla y divertida. Imagina que estás en una fiesta y hay demasiada gente queriendo usar el mismo baño. Al final, alguien se quedará esperando fuera, ¿verdad? Algo similar pasa con PostgreSQL cuando se queda sin memoria compartida para gestionar los bloqueos de los objetos. Este error suele aparecer cuando hay demasiados objetos bloqueados en una sola transacción o cuando el parámetro max_locks_per_transaction está configurado demasiado bajo. ¿Por qué ocurre este error? Las principales causas son: Muchas transacciones concurrentes : Cuando hay demasiadas transacciones al mismo tiempo, todas compitiendo por recursos. Operaciones complejas : Transacciones que bloquean muchos objetos a la vez, ...