Warstwowa pamięć masowa z BTRFS - jak to się robi?

Dec 08 2020

NETGEAR używa BTRFS w swoim ReadyNAS OS i wdraża warstwową pamięć masową w swoich najnowszych wersjach. Zaczęli od warstwy „Metadane” tylko w wersji ReadyNAS 6.9, a następnie dodali „Warstwę danych” w wersji 6.10. System wykorzystuje dyski SSD jako warstwę 0, aby przyspieszyć dostęp do wolniejszych dysków twardych w systemie. W opisie systemu stwierdza się, że metadane będą rezydować na dyskach SSD w obu przypadkach i że w przypadku „Warstwy danych” również nowo zapisane dane będą najpierw trafiać na dyski SSD, a następnie będą okresowo migrowane na dysk twardy lub gdy Poziom SSD wypełnia się do określonego poziomu.

ReadyNAS używa BTRFS na dyskach twardych z RAID w normalnych instalacjach - np. Mój system ma RAID5 złożony z 4 dysków, które BTRFS widzi / używa jako jedno urządzenie.

Patrząc na sposób implementacji warstwowania, wygląda na to, że zarówno konfiguracje „Metadanych”, jak i „Warstwy danych” są wykonywane przez dodanie drugiej macierzy RAID, składającej się wyłącznie z dysków SSD, do głównej macierzy RAID dysków twardych i przekształcenie początkowej macierzy RAID z jednym urządzeniem BTRFS na wiele urządzeń.

Nie mogę się dowiedzieć, w jaki sposób odbywa się migracja, a także w jaki sposób sprawa „Metadane” udaje się oddzielić metadane od danych, tak aby tylko metadane trafiały na dysk SSD? Ponadto, w jaki sposób tryb „Warstwa danych” kieruje całkowicie zapisy do warstwy SSD?

Jakieś pomysły?

Odpowiedzi

2 StefanPiperov Dec 13 2020 at 09:30

OK, oto co odkryłem podczas okresowych bilansów:

Na hoście zostaje uruchomiony następujący proces:

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

gdzie / data to mój wielowarstwowy wolumin danych, / dev / md127 to tablica SSD używana jako bufor / pamięć podręczna.

Ten proces trwa, dopóki dane z warstwy SSD nie zostaną prawie całkowicie przeniesione do warstwy HDD - np. Gdzieś po drodze widzę:

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

a następnie spada, aż użycie warstwy SSD spadnie prawie do zera. Dziwne jest to, że do tej pory nie mogłem ręcznie uruchomić tego polecenia.

Nadal nie mogę rozgryźć filtra równowagi „sweep”.

Oto, co pokazuje -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

ale to nie wyjaśnia, w jaki sposób mapuje się na " lt:/dev/md127:7" część polecenia, która jest uruchamiana okresowo:

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

Jakie jest tutaj znaczenie: Uruchom, dopóki użycie danych / dev / md127 nie spadnie poniżej 7%?!?

1 Blitzer Dec 09 2020 at 08:13

Musi to być cronjob, który działa regularnie i wykonuje migrację.

Sprawdź /etc/cron.d pod kątem wpisów, które mogą to robić.

1 zilexa Dec 31 2020 at 08:19

Mówisz, że Netgear znalazł sposób na zrobienie tego, na co już pozwala Tiered Caching MergerFS, w przyjaznej dla użytkownika i niezwykle prostej konfiguracji: https://github.com/trapexit/mergerfs#tiered-caching

  1. utwórz 2 pule MergerFS A) jedną ze wszystkimi dyskami HDD, w tym dyskami SSD („POOL”, tier0) i ustaw zapis na urządzeniu z najmniejszą ilością wolnego miejsca (chyba że pozostało X). B) druga pula („POOL-ARCHIWUM”, poziom 1) zawierająca tylko dyski twarde.

  2. Użytkownicy i wszystkie aplikacje używają tylko ścieżki pierwszej puli.

  3. Skrypt nocny, który kopiuje wszystko, co nie zostało dotknięte przez ostatnie X dni z pierwszej puli do drugiej (łatwe, ponieważ dyski są takie same, spowoduje to tylko skopiowanie danych na SSD). To jedyny element, który używa ścieżki drugiej puli.

Dokładnie tak skonfigurowałem mój serwer domowy. Wszystkie dyski są sformatowane w formacie BtrFS. Nie (nie mogę z tym rozwiązaniem) korzystać z Raida.

Profesjonaliści:

  1. Kiedy dysk ulegnie awarii, tracisz tylko dane na tym dysku (i ograniczam to, używając SnapRAID jako pierwszego systemu kopii zapasowych). Nie tracisz całej puli, jak w przypadku BtrFS-RAID0.
  2. Jest to niezwykle łatwe w konfiguracji. 2 montowania w twoim / etc / fstab. BAM, warstwowe buforowanie!
  3. Zawsze najpierw używasz dysku SSD (chyba że zostało na nim tylko X wolnego miejsca). Daje maksymalną prędkość.

Wady:

  1. Nie można używać podwoluminów BtrFS (obejmujących dyski) w ramach puli MergerFS, ponieważ MergerFS działa na systemach plików w przestrzeni użytkownika.
  2. Oznacza to również, że nie możesz tworzyć migawek podwoluminów w swojej puli. Chciałbym mieć maszynę czasu, taką jak migawki dla folderów danych użytkownika w mojej puli.

Absolutnie uwielbiam MergerFS za jego prostotę, ale con # 2 bardzo mnie interesuje tym, jak Netgear zhakował podobne rozwiązanie przy użyciu BTRFS.