Almacenamiento por niveles con BTRFS: ¿cómo se hace?

Question

NETGEAR usa BTRFS en su sistema operativo ReadyNAS e implementa el almacenamiento por niveles en sus últimas versiones. Comenzaron con el nivel "Metadatos" solo en ReadyNAS v6.9, y luego agregaron "Nivel de datos" en v6.10. El sistema utiliza SSD como Nivel 0 para acelerar el acceso a los discos duros más lentos del sistema. La descripción del sistema establece que los metadatos residirán en los SSD en ambos casos, y que en el caso del "Nivel de datos" también los datos recién escritos irán primero a los SSD y luego se migrarán al HDD periódicamente, o cuando el El nivel SSD se llena hasta un nivel específico.

ReadyNAS usa BTRFS en la parte superior de los HDD con RAID en sus instalaciones normales, por ejemplo, mi sistema tiene un RAID5 hecho de 4 discos, que BTRFS ve / usa como un solo dispositivo.

Al observar cómo se implementa la clasificación por niveles, parece que las configuraciones de "Metadatos" y "Nivel de datos" se realizan agregando una segunda matriz RAID, hecha solo de SSD, a la matriz RAID de HDD principal y transformando el dispositivo único inicial BTRFS en uno de dispositivos múltiples.

Lo que no puedo entender es cómo se realiza la migración y también cómo el caso de "Metadatos" logra separar los metadatos de los datos, de modo que solo los metadatos vayan a SSD. Además, ¿cómo dirige el modo "Nivel de datos" las escrituras por completo al nivel SSD?

¿Algunas ideas?

Answer 1

Bien, esto es lo que encontré sucediendo durante los saldos periódicos:

El siguiente proceso se inicia en el host:

btrfs balance start -dsweep lt:/dev/md127:7 /data LANG=en_US.UTF-8 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin DBUS_SESSION_BUS_ADDRESS=unix:path=/var/netatalk/spotlight.ipc TRACKER_USE_CONFIG_FILES=1 TRACKER_USE_LOG_FILES=1 XDG_DATA_HOME=/apps/.xdg/local/share XDG_CONFIG_HOME=/apps/.xdg/config XDG_CACHE_HOME=/apps/.xdg/cache

donde / data es mi volumen de datos escalonado, / dev / md127 es la matriz SSD utilizada como búfer / caché.

Este proceso se ejecuta hasta que los datos del nivel de SSD se mueven casi por completo al nivel de HDD, por ejemplo, en algún lugar del camino veo:

btrfs fi sh /data
Label: '0a44c6bc:data'  uuid: ed150b8f-c986-46d0-ada8-45ee219acbac
    Total devices 2 FS bytes used 393.14GiB
    devid    1 size 7.12TiB used 359.00GiB path /dev/md126
    devid    2 size 114.68GiB used 42.06GiB path /dev/md127

y luego baja hasta que el uso del nivel SSD llega casi a cero. Lo extraño es que hasta ahora no pude ejecutar este comando manualmente.

Todavía no puedo entender el filtro de equilibrio de 'barrido'.

Esto es lo que muestra -help:

# btrfs balance start --help
usage: btrfs balance start [options] <path>

    Balance chunks across the devices

    Balance and/or convert (change allocation profile of) chunks that
    passed all filters in a comma-separated list of filters for a
    particular chunk type.  If filter list is not given balance all
    chunks of that type.  In case none of the -d, -m or -s options is
    given balance all chunks in a filesystem. This is potentially
    long operation and the user is warned before this start, with
    a delay to stop it.

    -d[filters]    act on data chunks
    -m[filters]    act on metadata chunks
    -s[filters]    act on system chunks (only under -f)
    -v             be verbose
    -f             force reducing of metadata integrity
    --full-balance do not print warning and do not delay start
    --background|--bg
                   run the balance as a background process

pero esto no explica cómo se asigna " lt:/dev/md127:7" a la parte del comando que se ejecuta periódicamente:

btrfs balance start -dsweep lt:/dev/md127:7 /data

¿Cuál es el significado aquí: ejecutar hasta que el uso de datos de / dev / md127 caiga por debajo del 7%?

Answer 2

Debe ser un trabajo cron que se ejecute regularmente y realice la migración.

Compruebe /etc/cron.d para ver las entradas que podrían estar haciendo eso.

Answer 3

Está diciendo que Netgear ha encontrado una manera de hacer lo que MergerFS Tiered Caching le permite hacer, en una configuración fácil de usar y extremadamente simple: https://github.com/trapexit/mergerfs#tiered-caching

1. cree 2 grupos MergerFS A) uno con todas las unidades HDD, incluido el SSD ("POOL", tier0) y configúrelo para escribir en el dispositivo con el menor espacio libre (a menos que tenga X cantidad de espacio libre disponible). B) segundo grupo ("POOL-ARCHIVE", tier1) que solo contiene los HDD.

2. Sus usuarios y todas las aplicaciones solo usan la ruta del primer grupo.

3. Un script nocturno que copia todo lo que no se ha tocado durante los últimos X días del primer grupo al segundo (fácil, ya que las unidades son las mismas, esto solo hará que se copien los datos en el SSD). Este es el único elemento que usa la ruta del segundo grupo.

Así es exactamente como configuré mi servidor doméstico. Todas las unidades están formateadas en BtrFS. No (no puedo, con esta solución) uso Raid.

Los profesionales:

1. Cuando una unidad falla, solo pierdes datos en esa unidad (y esto lo mitigo usando SnapRAID como primer sistema de respaldo). No pierde todo el grupo como con BtrFS-RAID0.
2. Esto es extremadamente fácil de configurar. 2 montajes en su / etc / fstab. ¡BAM, almacenamiento en caché por niveles!
3. Siempre usa el SSD primero (a menos que solo le quede X cantidad de espacio libre). Dándote la máxima velocidad.

Los contras:

1. No puede usar subvolúmenes BtrFS (que abarcan todos los discos) dentro de su grupo MergerFS, ya que MergerFS se ejecuta sobre los sistemas de archivos en el espacio del usuario.
2. Esto también significa que no puede hacer instantáneas de subvolúmenes dentro de su grupo. Me encantaría tener instantáneas como máquinas del tiempo por carpetas de datos de usuario en mi grupo.

Me encanta MergerFS por su simplicidad, pero la con # 2 me hace muy interesado en cómo Netgear hackeó una solución similar usando BTRFS.