BTRFSを使用した階層型ストレージ-どのように実行されますか？

Dec 08 2020

NETGEARはReadyNASOSでBTRFSを使用し、最新バージョンで階層型ストレージを実装しています。ReadyNAS v6.9でのみ「メタデータ」層から開始し、v6.10で「データ層」を追加しました。システムはSSDをTier-0として使用して、システム内の低速のHDDへのアクセスを高速化します。システムの説明では、どちらの場合もメタデータはSSDに存在し、「データ層」の場合も、新しく書き込まれたデータは最初にSSDに送られ、その後定期的に、またはSSD層は指定されたレベルまでいっぱいになります。

ReadyNASは、通常のインストールでRAID化されたHDDの上にBTRFSを使用します。たとえば、私のシステムには4つのディスクで構成されるRAID5があり、BTRFSはこれを単一のデバイスとして認識/使用します。

階層化の実装方法を見ると、「メタデータ」と「データ層」の両方のセットアップは、SSDのみで構成される2番目のRAIDアレイをメインのHDD RAIDアレイに追加し、最初の単一デバイスを変換することによって行われているように見えます。 BTRFSを複数のデバイスに変換します。

私が理解できないのは、移行がどのように行われるか、また「メタデータ」ケースがメタデータをデータから分離して、メタデータのみがSSDに送られるようにする方法です。また、「データ層」モードはどのようにして書き込みを完全にSSD層に向けますか？

何か案は？

回答

2 StefanPiperov Dec 13 2020 at 09:30

OK、これが定期的なバランスの間に起こっていることを私が見つけたものです：

次のプロセスがホストで開始されます。

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

ここで、/ dataは階層化されたデータボリューム、/ dev / md127はバッファー/キャッシュとして使用されるSSDアレイです。

このプロセスは、SSD層からのデータがほぼ完全にHDD層に移動するまで実行されます。たとえば、次のようになります。

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

その後、SSD層の使用量がほぼゼロになるまで低下します。奇妙なことに、これまでこのコマンドを手動で実行できませんでした。

私はまだ「スイープ」バランスフィルターを理解できません。

これは-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

ただし、これはlt:/dev/md127:7、定期的に実行されるコマンドの「」部分にどのようにマップされるかを説明していません。

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

ここでの意味は何ですか：/ dev / md127のデータ使用量が7％を下回るまで実行しますか？！？

1 Blitzer Dec 09 2020 at 08:13

定期的に実行され、移行を行うcronジョブである必要があります。

/etc/cron.dで、それを実行している可能性のあるエントリを確認してください。

1 zilexa Dec 31 2020 at 08:19

Netgearは、MergerFS Tiered Cachingですでに実行できることを、ユーザーフレンドリーで非常にシンプルな構成で実行する方法を見つけたと言っています。 https://github.com/trapexit/mergerfs#tiered-caching

2つのMergerFSプールを作成します。A）SSD（ "POOL"、tier0）を含むすべてのHDDドライブを備えたプールを作成し、空き容量が最小のデバイスに書き込むように設定します（X個の空き容量が残っている場合を除く）。B）HDDのみを含む2番目のプール（ "POOL-ARCHIVE"、tier1）。
ユーザーとすべてのアプリケーションは、最初のプールのパスのみを使用します。
過去X日間に触れられなかったすべてのものを最初のプールから2番目のプールにコピーする夜間のスクリプト（ドライブが同じであるため、SSD上のデータのみがコピーされるのは簡単です）。これは、2番目のプールのパスを使用する唯一のアイテムです。

これはまさに私がホームサーバーを設定した方法です。すべてのドライブはBtrFS形式です。私はレイドを使用しません（このソリューションでは使用できません）。

長所：

ドライブに障害が発生すると、そのドライブのデータが失われるだけです（そして、SnapRAIDを最初のバックアップシステムとして使用することでこれを軽減します）。BtrFS-RAID0のようにプール全体を失うことはありません。
これはセットアップが非常に簡単です。/ etc / fstabに2つのマウント。BAM、階層型キャッシュ！
常に最初にSSDを使用します（X個の空き容量しかない場合を除く）。あなたに最高速度を与えます。

短所：

MergerFSはユーザースペースのファイルシステム上で実行されるため、MergerFSプール内で（ディスクにまたがる）BtrFSサブボリュームを使用することはできません。
これは、プール内のサブボリュームのスナップショットを作成できないことも意味します。プール内のユーザーデータフォルダーごとにスナップショットのようなタイムマシンが欲しいです。

私はMergerFSのシンプルさが大好きですが、con＃2は、NetgearがBTRFSを使用して同様のソリューションをハッキングした方法に非常に興味を持っています。