uVersion
Español
Descargar →

Wiki

Almacenamiento y GC

La vista Storage de la pestaña Files: panel de almacenamiento por repositorio (tamaño, deduplicación, crecimiento) y garbage collection, purga de revisiones antiguas, chunks huérfanos, phantom files.

Introducción

La vista Storage muestra el uso de disco de un repositorio (un proyecto versionado en el servidor) y ofrece una herramienta de garbage collection (GC) para recuperar espacio purgando las revisiones antiguas y los datos que han dejado de ser útiles.

Dónde encontrarla Elige el repositorio en el selector de la fila PROJECT, abre la pestaña Files de esa misma fila y luego cambia a la vista Storage con los dos botones Browse / Storage en la parte superior de la pestaña. La vista Browse sirve para recorrer los archivos del repositorio; todo lo que describe esta página se encuentra en la vista Storage.
La pestaña Files con los dos botones Browse y Storage en la parte superior, siendo Storage el botón activo.

Acceso y roles

La pestaña Files y su vista Storage son accesibles para el super admin y para el project_admin en los repositorios que administra, incluido el lanzamiento del GC. En cambio, las estadísticas globales del servidor y la licencia quedan reservadas al super admin (en otro lugar del panel).

Las métricas

La vista Storage se abre con tres tarjetas, Total Size, Files / Revisions y Dedup Ratio. Vienen luego el histograma Growth (Last 30 Days) y después la tabla Largest Files. El botón de actualización, arriba a la izquierda, recalcula el conjunto.

La vista Storage: las tres tarjetas Total Size, Files / Revisions y Dedup Ratio arriba, el histograma Growth (Last 30 Days) debajo, y después la tabla Largest Files con sus columnas Path, Size y Revisions.

Lo que significa cada cifra:

  • Total Size: el tamaño total de los archivos, justo debajo el tamaño comprimido realmente ocupado en el disco.
  • Files / Revisions: el número de archivos y, debajo, el número de revisiones y de chunks.
  • Dedup Ratio (%): la parte del espacio ahorrada gracias al uso compartido de chunks y a la compresión.
  • Growth (Last 30 Days): el tamaño acumulado día a día. Pasa el cursor sobre una barra para leer su fecha, su tamaño y su número de revisiones.
  • Largest Files: los 20 archivos más grandes, con su tamaño y su número de revisiones.

Estas cifras ayudan a detectar un repositorio que se hincha: un archivo binario voluminoso que se vuelve a commitear a menudo, o un crecimiento anómalo en los últimos 30 días.

Garbage collection

El bloque Garbage Collection se encuentra en la parte inferior de la vista Storage. Purga el historial antiguo según dos parámetros:

ParámetroPredeterminadoFunción
Retention (days)90Antigüedad por debajo de la cual una revisión siempre se conserva.
Min revisions to keep5Número de revisiones recientes conservadas por archivo, sea cual sea su antigüedad.
El GC es destructivo e irreversible Las revisiones purgadas (más allá de la ventana de retención) no se recuperan, y Run GC no pide ninguna confirmación: basta el clic. Ejecuta un Preview antes de cada ejecución y comprueba que las cifras coinciden con lo que esperas.

1. Ajustar los dos parámetros

Introduce Retention (days) y Min revisions to keep en los dos campos, a la izquierda de los botones. Llegan con los valores predeterminados de la tabla anterior, 90 y 5. Recuerda: una revisión solo se purga si se cumplen ambas condiciones.

2. Lanzar una vista previa con Preview

Preview simula la purga sin eliminar nada. Aparece un banner amarillo debajo de los botones: «Preview: X revisions would be deleted across Y files, Z phantom file entries would be removed». Es el momento de comprobar el orden de magnitud; si el número te sorprende, sube la retención en lugar de lanzar.

El bloque Garbage Collection: los campos Retention (days) y Min revisions to keep, los botones Preview y Run GC, y el banner amarillo de la vista previa debajo.

3. Ejecutar con Run GC

El botón rojo Run GC ejecuta la purga. El banner verde de fin anuncia «GC complete: X revisions deleted, Y orphan chunks cleaned, Z phantom file entries removed», las métricas de arriba se recargan y la ejecución queda registrada en la auditoría.

El banner verde GC complete mostrado debajo de los botones tras un Run GC: el número de revisiones eliminadas, de chunks huérfanos limpiados y de entradas fantasma retiradas.

Qué elimina el GC

  1. Revisiones antiguas: las más antiguas que Retention (days) Y más allá de las Min revisions to keep más recientes por archivo. Después sus chunks, si ya no están referenciados por ninguna otra revisión.
  2. Chunks huérfanos: los bloques de datos que ninguna revisión usa ya tras la purga.
  3. Phantom files: filas de archivo que nunca se commitearon realmente (ruta inválida o una entrada que quedó en suspenso), más allá de una ventana fija de 7 días (no configurable).

Los marcadores de eliminación (tombstones) de los archivos borrados u obliterados se respetan: sirven para propagar la eliminación a los clientes durante la sync, y por eso no deben desaparecer.

Trampas frecuentes

El Preview anuncia muy poco

Es normal si el repositorio es reciente o si el historial cabe dentro de la retención. El GC solo toca las revisiones que son a la vez lo bastante antiguas y están más allá de las últimas N por archivo.

Preview y Run no muestran los mismos contadores

El Preview no puede predecir el número exacto de chunks ni de vínculos revisión-chunk eliminados: solo informa de las revisiones, los archivos escaneados y las entradas fantasma. Los chunks huérfanos solo aparecen en el Run.

Bajar la retención para recuperar espacio

Es posible, pero pierdes historial. En un proyecto donde hay que poder retroceder mucho en el tiempo, mantén una retención holgada y actúa más bien sobre los archivos grandes (consulta la lista de los archivos más grandes y el .uversionignore para evitar trackear artefactos regenerables).