Warstwowa pamięć masowa z BTRFS - jak to się robi?
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
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%?!?
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ć.
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
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.
Użytkownicy i wszystkie aplikacje używają tylko ścieżki pierwszej puli.
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:
- 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.
- Jest to niezwykle łatwe w konfiguracji. 2 montowania w twoim / etc / fstab. BAM, warstwowe buforowanie!
- Zawsze najpierw używasz dysku SSD (chyba że zostało na nim tylko X wolnego miejsca). Daje maksymalną prędkość.
Wady:
- 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.
- 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.