Cuando fstrim falla - Linux bajo HyperV 2012 R2
 

Trabajar con LINUX como casi cualquier otro sistema operativo tiene sus ventajas y sus desventajas... (si, si,... ya los escucho.. muchas más ventajas que Win... ok... puede ser..).

Dicho esto, pasa que como administradores solemos tener herramientas a las que nos acostumbramos y cuando nos fallan... nos pegamos la cabeza contra la pared.. o buscamos alternativas

Linux bajo HyperV (en este caso bajo 2012 R2)

Se que no es lo ideal, instalar un Linux bajo HyperV, pero más de una vez, de hecho ,... muchas veces es una opción o salida elegante.

Con algún que otro ajuste, he venido utilizando Linux para diferentes roles bajo HyperV, sin problema alguno...

Cada tanto, en período de mantenimiento preventivo, cuando se utilizan discos dinámigos, solemos "reclamar" el espacio libre de Linux para achicar los discos VHD o VHDX

En este caso, una distribución de ClearOS (léase CentOS), había ocupado alrededor de 150 GBs, cuando no debería superar los 7 u 8 GBs.

Pasos

Lo primero seria verificar dentro del Linux, cuando realmente de este espacio podríamos reclamar.. para lo que corremos el comando df via sudo root

En este caso, claramente tenemos mucho espacio para reclamar, como usualmente hacíamos, invocamos fstrim , para ello, el comando sería, fstrim / ya que queremos poner todo el espacio vacío a cero.

Se invoca fstrim / ya que para reducir el tamaño del disco vhd se require que el espacio vacío sea llenado con ceros, desde root, de forma que HyperV pueda editar el disco y reducirlo

Peeeeerrroooo... esta vez cuando llamamos a fstrim , nos encontramos con este problema...

...podríamos expandirnos en ver el origen del problema.. si el FileSystem no es compatible, si está encriptado, si no permite fstrim... etc. etc.. pero... la ventana de tiempo de trabajo se agota y es necesario comprimir el VHD y volver el Linux a producción

Alternativa

Nuevamente... una ventaja de Linux es que tenemos varias herramientas disponibles que hacen lo mismo..., en este caso.. fuimos por la alternativa dd

Básicamente, usamos dd para tomar un cero y pasarlo a un archivo en forma continua hasta que se llene el espacio libre o el usuario finalice la operación

La primer linea de comando, debe entenderse como dd if=origen of=destino, donde nuestro origen será una cadena de ceros y nuestra salida un archivo.
Durante la ejecución, el usuario puede cortar con Ctrl+C, pero no liberaría o mejor dicho, sobreescribiría todo el espacio vacío y por lo tanto no podría luego reducirse optimamente el archivo.

Una vez que la primer línea se ejecuta, lo que queda, es eliminar el archivo que ocupó todo el espacio libre, para asi poder luego reducir el VHD o VHDX

Pero si genero un archivo no hago crecer el VHD?

Es una buena pregunta, pero no... el VHD no va a crecer por espacio con ceros, ya que está diseñado para no crecer en vano.. asi que no.. no crecerá..

Compactación del VHD

Una vez que los comandos finalizaron, y se eliminó el archivo creado con ceros, pasaremos a apagar el linux shutdown -h now o el comando que gusten para apagado.. y luego via el editor de discos de HyperV pasaremos a compactar el disco

Con el Linux apagado, vamos al panel de acciones de HyperV y seleccionamos Edit Disk, HyperV nos guiará para que seleccionemos el disco que deseamos editar.
Una vez selecionado, avanzamos hasta llegar a la opción que nos permite seleccionar Compactar, luego presionamos Finish y verificamos y confirmamos que el disco es el que deseamos compactar

HyperV comenzará una barra de progreso, mientras compacta el disco y hasta que finalice, cosa que hace sin ningún aviso o alerta... lo que provoca para los no habituados que pensemos que algo falló...

Finalización

Cuando la barra de progreso llega a su fin, la ventana se cierra y el archivo estará compactado, y podremos volver a poner el equipo en línea.

En este caso.. los resultados fueron excelentes... de alrededor de 150 GBs a 7 GBs. No hace falta aclarar porque reducir el tamaño del disco es bueno, basta con pensar en el backup para determinar lo óptimo de esta tarea

Conclusiones

Como dije al inicio, trabajar con Linux brinda muchas posibilidades para concretar la misma tarea usando diferentes caminos... en este caso, sin dudas, fstrim / hubiera sido la mejor solución, ya que es mucho más rápida que la solución implementada... pero no funcionó.. y no había tiempo para pensar en el origen o causa de la falla de fstrim, simplemente el tiempo que teníamos demandaba que ejecutaramos algo para lograr el objetivo y eso se hizo.

Terminamos con esto??? de ninguna manera.. problema que se va sin que lo hechen.. vuelve sin que lo llamen.. pero la explicación de porque no funcionó fstrim.. la dejamos para la próxima...

 

 

Volver a lista de Notas