1 votos

¿Por qué mi sparsebundle no informa de que hay espacio libre y que sobra?

Tengo un sparsebundle creado por Time Machine (HFS+) que reporta los siguientes límites al usar hdiutil resize -limits :

 min     cur     max 
403186088   403186088   34359738368

Eso es un tamaño actual de 206 GB y un máximo de 17,5 TB . Llego a la conclusión de que no necesito hdiutil resize el sparsebundle para permitir su expansión. El volumen anfitrión tiene 200 GB adicionales libres, por lo que el paquete debería poder expandirse aproximadamente al 100%:

  • La utilidad de disco indica que el espacio libre es de 1 GB
  • Time Machine informa que el espacio libre es de 1 GB

Esperaba que detectaran 200 GB de espacio libre disponible en el volumen del host. Esto es un problema ya que Time Machine empezará a borrar las copias de seguridad antes de tiempo.

¿Cómo puedo hacer que el sparsebundle se expanda cuando sea necesario para llenar el espacio disponible en el sistema de archivos del host?

Algunas preguntas adicionales que surgieron y que podrían ayudar a acotar el tema:

  1. ¿Qué parte del sistema es responsable de ampliar el paquete ¿cuándo es necesario? ¿Hace esto Time Machine explícitamente o lo hace de forma transparente por debajo de él? Es decir, ¿es un problema de Time Machine o de algo más fundamental?
  2. ¿Hay algo más forma fiable de comprobar si Time Machine se ha quedado/se quedará sin espacio que mirar la cifra de "espacio libre" en los ajustes de Time Machine? Es decir, ¿se puede confiar en las cifras? He eliminado y añadido el paquete como destino de la copia de seguridad con tmutil setdestination antes de comprobar el espacio libre.
  3. Si Time Machine se encarga explícitamente de expandir un sparsebundle utilizado como destino de la copia de seguridad, ¿sólo lo hará cuando él mismo monte el sparsebundle como un paso de una copia de seguridad en red ? En otras palabras, al tomar la unidad en red y conectarla localmente con USB3, y luego montar manualmente el sparsebundle, ¿podría Time Machine simplemente omitir el paso en el que normalmente expande el objetivo del sparsebundle, ya que el paquete se considera ahora almacenamiento local (que generalmente no utiliza sparsebundles)?

MacOS Mojave 10.14.6


Actualización

Hay varias razones sutiles que se combinan en por qué creo que mi sparsebundle no se expande automáticamente, y por qué formé la hipótesis nula de que el espacio libre reportado por Time Machine no es erróneo. Ellos incluyen:

  • No tengo ninguna buena razón para suponer que el número reportado en Time Machine y en la interfaz de la Utilidad de Discos sea erróneo. Por el contrario, no me han dado ninguna garantía explícita de que el volumen de destino se expandirá, ni en qué medida.
  • Según recuerdo, Time Machine ya ha fallado anteriormente en ampliar el objetivo de sparsebundle en el que estaba haciendo la copia de seguridad, a pesar de tener mucho espacio disponible en el volumen anfitrión.
  • El historial de diseño de Apple me sugiere que si sólo expusieran una única cifra (espacio restante disponible) en la interfaz de usuario de Time Machine para que yo basara mis decisiones con respecto a las acciones que tomará TM a su vez, ya la habrían eliminado si fuera una cifra poco fiable. No considero que el uso de sparsebundles (es decir, la copia de seguridad en red) sea un caso tan pequeño como para justificar que se ignore ese nivel de falta de fiabilidad en su fase de diseño de la UI.
  • Cuando la unidad se utiliza como objetivo de red, TM parece informar de ~200/400 GB disponibles, mientras que conectada como objetivo de copia de seguridad local informará de ~200/200 GB disponibles. Un sparsebundle montado localmente tampoco aparece en la interfaz de usuario "add target" en TM, sino que tiene que ser añadido usando tmutil . Esto sugiere una incoherencia en el manejo de los objetivos de las copias de seguridad y que Time Machine gestiona los sparsebundles explícitamente.

Me doy cuenta de que esto no es concluyente, así que lo probé:

  1. Monté el volumen del host a través de USB, y procedí a redimensionar el sparsebundle con hdiutil para que fuera tan pequeño como pudiera hacerlo, de modo que pareciera tener ~20 GB libres según todas las herramientas de la interfaz gráfica del sistema. Se redujo en más de 100 GB en ese sentido, por lo que hay mucho espacio de sobra en el volumen anfitrión.
  2. Monté el paquete como un volumen local, y procedí a copiar un archivo Xcode.xip de 11 GB en él dos veces.
  3. La primera transferencia tuvo éxito.
  4. La segunda transferencia falló incluso antes de empezar: "no hay suficiente espacio libre". Se necesitaban 1,54 GB de espacio adicional. Esto era de esperar.
  5. Conclusión: el sparsebundle no se expandió de forma transparente, a pesar de tener más de 100 GB de espacio libre en el volumen anfitrión. No hay ninguna razón para creer que la cifra que informa Time Machine sea errónea, ni que el volumen se expanda de forma transparente durante el funcionamiento de TM.

2voto

Jose Chavez Puntos 645

En cuanto a su primera pregunta: Es el sistema operativo el que redimensiona automáticamente los paquetes dispersos según sea necesario cuando añades datos a ellos. Esto se hace de forma transparente bajo Time Machine, por lo que no es algo que Time Machine maneje explícitamente.

El paquete disperso en sí mismo puede tener una capacidad máxima que supere el espacio disponible en su unidad, ya que no ocupa realmente ningún espacio antes de escribir datos en él. Puedes cambiar su tamaño, pero en realidad no cambia nada sobre la cantidad de espacio que ocupa en la unidad física, sino que sólo impone un límite sobre la cantidad que eventualmente se puede escribir en él.

Aunque la Utilidad de Discos informa que no tiene espacio libre real, se expandirá automáticamente para llenar la unidad. Cuando la unidad física está llena, no es posible añadir más al paquete disperso hasta que se despeje el espacio o se mueva el paquete a una unidad más grande.

Cuando se ejecuta hdiutil resize -limits my.sparsebundle se obtendrá un valor mínimo, mínimo y máximo. Puedes utilizar los siguientes cálculos para obtener números "legibles para el ser humano" para ellos:

  min * 512 / 1024 / 1024 = MB data stored in the sparsebundle

  cur * 512 / 1024 / 1024 = limit in MB of how much data can be added

  max * 512 / 1024 / 1024 = the largest limit in MB you can set

Puedes cambiar el límite en cualquier momento utilizando:

hdiutil resize -size 500MB my.sparsebundle

Esto cambiaría el límite a 500 MB. Obviamente, no tiene sentido establecer un límite inferior a la cantidad actual de datos almacenados. Tal vez un poco contra intuitivo, el límite puede ser fijado más alto que la cantidad de espacio de disco que realmente tiene disponible. Sin embargo, el límite no puede ser más alto que el max que en su caso es de 16 TB. La razón de los 16 TB es que lo tienes configurado con un tamaño de bloque de 4 kB. Puedes crear paquetes dispersos con un tamaño de bloque mayor para obtener un valor máximo más alto hasta el máximo teórico de casi 8 exabytes.

Tenga en cuenta que este límite no tiene nada que ver con la cantidad de espacio de disco que realmente se ocupa en su disco físico. Puedes encontrar este número ejecutando por ejemplo:

du -sh my.sparsebundle

Si, por ejemplo, utilizas la Utilidad de Discos para crear un sparsebundle vacío con un tamaño de 500 MB formateado con APFS, verás que el comando anterior te dice que sólo ocupa unos 13 MB en el disco físico.

Cuando se monta el sparsebundle y se le añaden archivos, la cantidad de espacio que ocupa el disco físico aumenta. Es decir, el sistema operativo expande de forma transparente la estructura del sparsebundle en el disco físico para acomodar los datos extra que le añades. Sin embargo, no añadirá más que el límite arbitrario, que tú has establecido.

Si selecciona "Información" en el sparsebundle montado en Finder, le mostrará cuántos datos se han añadido al sparsebundle, así como la cantidad de espacio "Libre". Esta cantidad de espacio "Libre" no es la cantidad de espacio libre en su unidad física, sino la cantidad que queda hasta que llegue al límite (artificial) establecido en su sparsebundle, que puede cambiar en cualquier momento más tarde.

0voto

J.Doe Puntos 90

Posiblemente he mezclado los conceptos de min, cur y max.

Había asumido que cur representaba el espacio utilizado actualmente en el volumen del host, y no el espacio lógico total actual de la imagen. En este último caso, seguiría siendo necesario un redimensionamiento para aumentar el tamaño lógico disponible, lo que, en retrospectiva, resulta haber tenido el efecto deseado.


Para aclarar el problema a los futuros lectores (incluido yo mismo):

root de mi problema es que he tenido la impresión de que los sparsebundles se "expandirán" automáticamente, sin tener una idea clara de lo que se expandirá exactamente.

Como nunca me preocupó especialmente el hecho de que algo que es escaso ocupará potencialmente menos espacio que su espacio interno anunciado -porque eso sólo me beneficia a mí-, sólo había asumido que las menciones a cómo los sparsebundles pueden expandirse automáticamente se referían a un concepto separado, por ejemplo, la expansión del espacio de su volumen interno. Eso es algo que habría sido útil saber, ya que significaría que no tendría que preocuparme de que el volumen del paquete se llenara, siempre y cuando quedara espacio en el volumen anfitrión.

En otras palabras, aunque podía diferenciar entre el tamaño físico del paquete en el disco y el tamaño de su volumen interno, pensaba que este último tenía la capacidad de crecer automáticamente. El hdiutil La salida no ayudó a esa idea errónea.

No es de extrañar (a posteriori) que no funcione así. El tamaño del volumen es fijo hasta la intervención manual, y saber que su tamaño físico se "expande" automáticamente es sólo marginalmente útil, al menos para mi caso de uso.

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X