ZFS | 徒然なるままに

FreeBSD で ZFS を利用する – ZFS ファイルシステムの機能について理解する (4)

seichan — Wed, 03 Jan 2024 13:00:00 +0000

ZFS ファイルシステムで利用できる機能は多岐にわたります．今回はファイルシステム (と ZVOL) が持つ機能について説明を行います．
マニュアルをベースに抜粋してなるべく見やすいように記載をしているつもりです．
なお，マニュアルの参照元は zfsprops(7) です．

ZFS に関するお話

ZFS ファイルシステムプロパティ

作成済みの ZFS ファイルシステムのプロパティを表示するとこのように沢山の項目が表示されます．

# zfs get all pool0
NAME   PROPERTY              VALUE                  SOURCE
pool0  type                  filesystem             -
pool0  creation              Mon Dec 18 18:35 2023  -
pool0  used                  10.0G                  -
pool0  available             375G                   -
pool0  referenced            32.0K                  -
pool0  compressratio         1.00x                  -
pool0  mounted               yes                    -
pool0  quota                 none                   default
pool0  reservation           none                   default
pool0  recordsize            128K                   default
pool0  mountpoint            /pool0                 default
pool0  sharenfs              off                    default
pool0  checksum              on                     default
pool0  compression           off                    default
pool0  atime                 on                     default
pool0  devices               on                     default
pool0  exec                  on                     default
pool0  setuid                on                     default
pool0  readonly              off                    default
pool0  jailed                off                    default
pool0  snapdir               hidden                 default
pool0  aclmode               discard                default
pool0  aclinherit            restricted             default
pool0  createtxg             1                      -
pool0  canmount              on                     default
pool0  xattr                 on                     default
pool0  copies                1                      default
pool0  version               5                      -
pool0  utf8only              off                    -
pool0  normalization         none                   -
pool0  casesensitivity       sensitive              -
pool0  vscan                 off                    default
pool0  nbmand                off                    default
pool0  sharesmb              off                    default
pool0  refquota              none                   default
pool0  refreservation        none                   default
pool0  guid                  1264596009273225631    -
pool0  primarycache          all                    default
pool0  secondarycache        all                    default
pool0  usedbysnapshots       0B                     -
pool0  usedbydataset         32.0K                  -
pool0  usedbychildren        10.0G                  -
pool0  usedbyrefreservation  0B                     -
pool0  logbias               latency                default
pool0  objsetid              54                     -
pool0  dedup                 off                    default
pool0  mlslabel              none                   default
pool0  sync                  standard               default
pool0  dnodesize             legacy                 default
pool0  refcompressratio      1.00x                  -
pool0  written               32.0K                  -
pool0  logicalused           206K                   -
pool0  logicalreferenced     12.5K                  -
pool0  volmode               default                default
pool0  filesystem_limit      none                   default
pool0  snapshot_limit        none                   default
pool0  filesystem_count      none                   default
pool0  snapshot_count        none                   default
pool0  snapdev               hidden                 default
pool0  acltype               nfsv4                  default
pool0  context               none                   default
pool0  fscontext             none                   default
pool0  defcontext            none                   default
pool0  rootcontext           none                   default
pool0  relatime              off                    default
pool0  redundant_metadata    all                    default
pool0  overlay               on                     default
pool0  encryption            off                    default
pool0  keylocation           none                   default
pool0  keyformat             none                   default
pool0  pbkdf2iters           0                      default
pool0  special_small_blocks  0                      default

自分で設定が変えられる項目，変えられない項目がありますが，以下この並びに沿って解説を入れていきます．
前回は refcompressratio まで記載しましたので，今回はその続きになります．

written

このデータセットによって参照される，直前のスナップショット以降に書き込まれた (つまり，直前のスナップショットによって参照されていない) スペースの量です．

logicalused

このデータセットとそのすべての配下によって「論理的に」消費されるスペースの量．
used プロパティも参照してください．
論理スペースは圧縮の影響を無視してプロパティに表示され，アプリケーションが認識するデータの量に近い量を与えます．
ただし，メタデータによって消費されるスペースも含まれます．

logicalreferenced

値は on，off，opts になります．

このデータセットが「論理的に」アクセスされているスペースの量。
referenced のプロパティも参照してください．
論理スペースは圧縮の影響を無視してプロパティに表示され，アプリケーションが認識するデータの量に近い量を与えます．
ただし，メタデータによって消費されるスペースも含まれます．

volmode

値は default，geom，dev，none になります．

このプロパティは，ボリュームを OS に公開する方法を指定します．
これを Full に設定すると，ボリュームが本格的なブロックデバイスとして公開され，最大限の機能が提供されます．
geom は full のエイリアスで，互換性のために保持されています．
dev に設定すると，そのパーティションが非表示になります．
プロパティが none に設定されたボリュームは ZFS の外部には公開されませんが，バックアップ目的に適したスナップショット，クローン作成，複製などが可能です．
デフォルト値は Full です．

filesystem_limit

値はcount，none になります．

データセットツリーのこのポイントの下に存在できるファイルシステムとボリュームの数を制限します．
ユーザーが制限の変更を許可されている場合，制限は強制されません．
すでに filesystem_limit を持つファイルシステムの配下に filesystem_limit を設定した場合，上位の filesystem_limit は上書きされず，追加の制限が課されます．

snapshot_limit

値は count，none になります．

データセットとその配下に対して作成できるスナップショットの数を制限します．
すでに snapshot_limit を持つデータセットの配下に snapshot_limit を設定した場合も，上位の snapshot_limit は上書きされず，追加の制限が課されます．
ユーザーが制限の変更を許可されている場合，制限は強制されません．

filesystem_count

データセットツリー内のこの場所に存在するファイルシステムとボリュームの合計数．
この値は，データセットが存在するツリー内に filesystem_limit が設定されている場合にのみ使用されます．

snapshot_count

データセットツリー内のこの場所に存在するスナップショットの総数．
この値は，データセットが存在するツリー内に snapshot_limit が設定されている場合にのみ使用されます．

snapdev

値は hidden，visible です．

/dev/zvol/ の下にあるボリュームスナップショットデバイスを非表示にするか表示するかを制御します．
デフォルト値は非表示です．

acltype

値は off，nfsv4，posix です．

ACL を有効にするかどうか，有効にする場合はどのタイプの ACL を使用するかを制御します．

このプロパティが現在のプラットフォームでサポートされていないタイプの ACL に設定されている場合，動作は off に設定されている場合と同じです．

off

Linux のデフォルトでは，ファイルシステムの acltype プロパティが off に設定されている場合，ACL は無効になります．

noacl

off のエイリアスです．

nfsv4

FreeBSD のデフォルトは，NFSv4 スタイルの ZFS ACL を使用する必要があることを示します．
これらの ACL は，getfacl(1) および setfacl(1) を使用して管理できます．
nfsv4 ZFS ACL タイプは Linux ではまだサポートされていません．

posix

POSIX ACL を使用する必要があることを示します．POSIX ACL は Linux に固有であり，他のプラットフォームでは機能しません．
POSIX ACL は拡張属性として保存されます．したがって，設定されている既存の NFSv4 ACL は上書きされません．

context

Linux の SELinux に向けた設定なので省略します．

fscontext

Linux の SELinux に向けた設定なので省略します．

defcontext

Linux の SELinux に向けた設定なので省略します．

rootcontext

Linux の SELinux に向けた設定なので省略します．

relatime

値は on，off です．

atime=on が設定されている場合にアクセス時間が更新される方法を制御します．
このプロパティをオンにすると，アクセス時間が修正時間または変更時間に応じて更新されます．
アクセス時刻は，以前のアクセス時刻が現在の変更時刻よりも早かった場合，または既存のアクセス時刻が過去 24 時間以内に更新されていない場合にのみ更新されます．デフォルト値はオンです．
on および off の値は，マウントオプションの relatime および norelatime と同義です．

redundant_metadata

値は all，most，some，none です．

どのタイプでメタデータを冗長的に保存するかを制御します．
ZFS はメタデータの追加のコピーを保存するため，単一のブロックが破損した場合でも，失われるユーザーデータの量は制限されます．
この追加コピーは，プールレベルで提供される冗長性 (ミラーリングや RAID-Z など) に追加され，コピープロパティで指定された追加コピー (合計 3 つのコピーまで) に追加されます．
たとえば，プールがミラー化され，copys=2，redundant_metadata=most の場合，ZFS はほとんどのメタデータのコピー 6 つと，データと一部のメタデータのコピー 4 つを保存します．

all に設定すると，ZFS はすべてのメタデータの追加コピーを保存します．
ディスク上の 1 つのブロックが破損すると，最悪の場合、ユーザーデータの 1 つのブロック (recordsize のバイトの長さ) が失われる可能性があります．

most に設定すると，ZFS はほとんどのタイプのメタデータの追加コピーを保存します．
これにより，書き込む必要のあるメタデータが少なくなるため，ランダム書き込みのパフォーマンスが向上します．
実際には，ディスク上の 1 つのブロックが破損すると，最悪でも約 1000 ブロック (それぞれ recordsize バイト) のユーザーデータが失われる可能性があります．
どのメタデータブロックが冗長的に保存されるかの正確な動作は，将来のリリースで変更される可能性があります．

some に設定すると，ZFS は重要なメタデータのみの追加コピーを保存します．
これにより，書き込む必要のあるメタデータが少なくなるため，ファイル作成のパフォーマンスが向上します．
ディスク上の 1 つのブロックが破損すると，最悪の場合，1 つのユーザーファイルが失われる可能性があります．

none に設定すると，ZFS はメタデータのコピーを冗長的に保存しません．
ディスク上の 1 つのブロックが破損すると，データセット全体が失われる可能性があります．

デフォルト値は「all」です．

overlay

値は on，off です．

使用中のディレクトリ，または既にファイルやディレクトリが含まれているディレクトリへのマウントを許可します．
これは、Linux および FreeBSD ファイルシステムのデフォルトで利用可能なのマウント動作です．
これらのプラットフォームでは，このプロパティはデフォルトで on になっています．
他のプラットフォーム上の OpenZFS との一貫性を保つためにオーバーレイマウントを無効にするには，off に設定します．

encryption

値は off，on，aes-128-ccm，aes-192-ccm，aes-256-ccm，aes-128-gcm，aes-192-gcm，aes-256-gcm です．

このデータセットに使用される暗号化スイート (ブロック暗号，キーの長さ，およびモード) を制御します．
プールで暗号化機能を有効にする必要があります．
データセットの作成時にキー形式を設定する必要があります．

データセットの作成時に encryption=on を選択すると，デフォルトの暗号化スイート (現在は aes-256-gcm) が選択されます．
一貫したデータ保護を提供するには，データセットの作成時に暗号化を指定する必要があり，後で変更することはできません．

暗号化の詳細と注意事項については、zfs-load-key(8) の「encryption」セクションを参照してください．

keylocation

値は prompt，file:///file/path，https://address，http://address です．

zfs load-key や zfs mount -l などのコマンドで，デフォルトでユーザーの暗号化キーがどこからロードされるかを制御します．
このプロパティは，暗号化ルートである暗号化されたデータセットに対してのみ設定されます．
指定しない場合のデフォルト値は prompt です．

データセットの作成後に暗号化スイートを変更することはできませんが，キーの場所は zfs set または zfs change-key のいずれかを使用して変更できます．
プロンプトが選択されている場合，暗号化されたデータにアクセスする必要がある場合，ZFS はコマンドプロンプトでキーを要求します (詳細については、zfs load-key を参照してください)．
この設定では，標準入力ストリーム経由でキーを渡すこともできますが，ユーザーは秘密にしておく必要のあるキーをコマンドラインに置かないように注意する必要があります．
ファイルパスが選択されている場合，キーは指定された絶対ファイルパスからロードされます．
HTTPS または HTTP が選択された場合，コンパイル時の構成と実行時の可用性に応じて，fetch(3)，libcurl，または何も使用せずに GET されます．
SSL_CA_CERT_FILE 環境変数を設定して，連結された証明書ストアの場所を設定できます．
SSL_CA_CERT_PATH 環境変数を設定すると，認証局バンドルが含まれるディレクトリの場所をオーバーライドできます．
SSL_CLIENT_CERT_FILE および SSL_CLIENT_KEY_FILE 環境変数を設定して，クライアント証明書とそのキーへのパスを構成できます．

keyformat

値は raw，hex，passphrase です．

ユーザーの暗号化キーがどの形式で提供されるかを制御します．このプロパティは，データセットが暗号化されている場合にのみ設定されます．

raw キーと hex キーの長さは 32 バイトである必要があり，ランダムに生成される必要があります．
raw キーは次のコマンドで生成できます

# dd if=/dev/urandom bs=32 count=1 of=/path/to/output/key

パスフレーズの長さは 8 ～ 512 バイトである必要があり，使用前に PBKDF2 によって処理されます (pbkdf2iters プロパティを参照してください)．
データセットの作成後に暗号化スイートを変更することはできませんが，キー形式は zfs change-key を使用して変更できます．

pbkdf2iters

値は iterations です．

パスフレーズ暗号化キーを処理して暗号化キーにする際に実行する PBKDF2 の反復回数を制御します．
このプロパティは，暗号化が有効であり，パスフレーズのキー形式が選択されている場合にのみ定義されます．
PBKDF2 の目標は，ユーザーのパスフレーズを総当たり攻撃するために必要な計算の難易度を大幅に高めることです．
これは，攻撃者が結果のキーに到達する前に，計算量の多いハッシュ関数を介して各パスフレーズを何度も実行することを強制することで実現されます．
実際にパスフレーズを知っているユーザーは，このコストを一度支払うだけで済みます．
CPU の処理能力が向上するにつれて，ブルートフォース攻撃が依然として不可能であることを保証するために，この数値を上げる必要があります．
現在のデフォルトは 350000 で、最小値は 100000 です．
このプロパティは、zfs change-key を使用して変更できます．

special_small_blocks

値は size です．

この値は，小さなファイルブロックを特別な割り当てクラスに含めるためのブロックサイズのしきい値を表します．
この値以下のブロックは特別割り当てクラスに割り当てられ，それより大きいブロックは通常クラスに割り当てられます．
有効な値は、0 または 512 から 1048576 (1 MiB) までの 2 のべき乗です．
デフォルトのサイズは 0 で，小さなファイルブロックが特殊クラスに割り当てられないことを意味します．

このプロパティを設定する前に，特別なクラス vdev をプールに追加する必要があります．
特別な割り当てクラスの詳細については，zpoolconcepts(7) を参照してください．

以上，4回にわたって掲載してみましたが，ZFS ファイルシステムプロパティの解説になります．
マニュアルが用意されている事のありがたさを感じつつも，読んでもぱっとわからない自分の無知を呪います．

どこかのタイミングで ZFS の暗号化もやってみたいと思いますが，一旦は ZFS については一区切りにしようと考えています．

FreeBSD で ZFS を利用する – ZFS ファイルシステムの機能について理解する (3)

seichan — Tue, 02 Jan 2024 13:00:00 +0000

ZFS に関するお話

ZFS ファイルシステムプロパティ

作成済みの ZFS ファイルシステムのプロパティを表示するとこのように沢山の項目が表示されます．

# zfs get all pool0
NAME   PROPERTY              VALUE                  SOURCE
pool0  type                  filesystem             -
pool0  creation              Mon Dec 18 18:35 2023  -
pool0  used                  10.0G                  -
pool0  available             375G                   -
pool0  referenced            32.0K                  -
pool0  compressratio         1.00x                  -
pool0  mounted               yes                    -
pool0  quota                 none                   default
pool0  reservation           none                   default
pool0  recordsize            128K                   default
pool0  mountpoint            /pool0                 default
pool0  sharenfs              off                    default
pool0  checksum              on                     default
pool0  compression           off                    default
pool0  atime                 on                     default
pool0  devices               on                     default
pool0  exec                  on                     default
pool0  setuid                on                     default
pool0  readonly              off                    default
pool0  jailed                off                    default
pool0  snapdir               hidden                 default
pool0  aclmode               discard                default
pool0  aclinherit            restricted             default
pool0  createtxg             1                      -
pool0  canmount              on                     default
pool0  xattr                 on                     default
pool0  copies                1                      default
pool0  version               5                      -
pool0  utf8only              off                    -
pool0  normalization         none                   -
pool0  casesensitivity       sensitive              -
pool0  vscan                 off                    default
pool0  nbmand                off                    default
pool0  sharesmb              off                    default
pool0  refquota              none                   default
pool0  refreservation        none                   default
pool0  guid                  1264596009273225631    -
pool0  primarycache          all                    default
pool0  secondarycache        all                    default
pool0  usedbysnapshots       0B                     -
pool0  usedbydataset         32.0K                  -
pool0  usedbychildren        10.0G                  -
pool0  usedbyrefreservation  0B                     -
pool0  logbias               latency                default
pool0  objsetid              54                     -
pool0  dedup                 off                    default
pool0  mlslabel              none                   default
pool0  sync                  standard               default
pool0  dnodesize             legacy                 default
pool0  refcompressratio      1.00x                  -
pool0  written               32.0K                  -
pool0  logicalused           206K                   -
pool0  logicalreferenced     12.5K                  -
pool0  volmode               default                default
pool0  filesystem_limit      none                   default
pool0  snapshot_limit        none                   default
pool0  filesystem_count      none                   default
pool0  snapshot_count        none                   default
pool0  snapdev               hidden                 default
pool0  acltype               nfsv4                  default
pool0  context               none                   default
pool0  fscontext             none                   default
pool0  defcontext            none                   default
pool0  rootcontext           none                   default
pool0  relatime              off                    default
pool0  redundant_metadata    all                    default
pool0  overlay               on                     default
pool0  encryption            off                    default
pool0  keylocation           none                   default
pool0  keyformat             none                   default
pool0  pbkdf2iters           0                      default
pool0  special_small_blocks  0                      default

自分で設定が変えられる項目，変えられない項目がありますが，以下この並びに沿って解説を入れていきます．
前回は casesensitivity まで記載しましたので，今回はその続きになります．

vscan

値は on，off になります．

ファイルを開いたり閉じたりするときに，通常のファイルのウイルススキャンを行うかどうかを制御します．
ウイルススキャンを実行するには，このプロパティを有効にすることに加えて，ウイルススキャンサービスも有効にする必要があります．
デフォルト値は off です．また，このプロパティは OpenZFS では使用されません．
(したがって，FreeBSD では利用ができません)

nbmand

値は on，off になります．

ファイルシステムを nbmand (ノンブロッキング必須ロック) でマウントするかどうかを制御します．
このプロパティへの変更は，ファイルシステムがアンマウントされ，再マウントされた際に有効になります．
また，これは 5.15 より前の Linux でのみサポートされており，そこでバグがあったため，FreeBSD ではサポートされていません．
Solaris では，SMB クライアントに使用されます．

sharesmb

値は on，off，opts になります．

Samba USERSHARES を使用してファイルシステムを共有するかどうか，およびどのようなオプションを使用するかを制御します．
それ以外の場合，ファイルシステムは、zfs share および zfs unshare コマンドを使用して自動的に共有および共有解除されます．
このプロパティが on に設定されている場合，net(8) コマンドが呼び出され、USERSHARE が作成されます．

SMB 共有にはリソース名が必要なため，データセット名から一意のリソース名が構築されます．
構築された名前は，データセット名のコピーですが，リソース名では無効となるデータセット名の文字がアンダースコア (_) 文字に置き換えられます．
Linux は現在，Solaris で利用できる追加オプションをサポートしていません．

sharesmb プロパティが off に設定されている場合，ファイルシステムは共有されません．

共有は ACL (アクセスコントロールリスト)「Everyone:F」(「F」は「フルアクセス許可」，つまり読み取りおよび書き込みアクセス許可を表します) を使用して作成され、ゲストアクセスはありません (つまり、Samba は実際のユーザーを認証できる必要があります)．
デフォルトでは passwd(5)/shadow(5)、LDAP、または smbpasswd(5)．
これは，追加のアクセス制御 (特定のユーザー固有のアクセスを禁止するなど) を基盤となるファイルシステムで実行する必要があることを意味します．

sharesmb プロパティが zfs set -u で更新されると，プロパティは目的の値に設定されますが，データセットを共有，再共有，または共有解除する操作は実行されません．

refquota

値は size，none になります．

データセットが消費できるスペースの量を制限します．
このプロパティは、使用されるスペースの量に厳しい制限を適用します．
このハード制限には，quota プロパティと違って，ファイルシステムやスナップショットなど，子孫によって使用される領域は含まれません．

refreservation

値は size，none になります．

データセットに対して保証される最小領域を設定できます (配下は含まれません)．
使用されるスペースの量がこの値を下回っている場合，データセットは、refreservation で指定されたスペースの量を占有しているかのように扱われます．
refreservation による予約は，親データセットの使用スペースに考慮され，親データセットのクォータと reservation に対してカウントされます．

refreservation が設定される場合，スナップショットは，データセット内の現在の「referenced」バイト数を収容するのに十分な空き領域がこの予約以外存在する場合にのみ許可されます．
refreservation が auto に設定されている場合，ボリュームはシックプロビジョニングされます．
refreservation=auto はボリュームでのみサポートされます．
スパースボリュームの詳細については、「Native Properties」セクションの volsize を参照してください．
このプロパティは、短縮された列名 refreserv によって参照することもできます。

guid

このデータセットまたはブックマークの 64 ビット GUID です．
データセット，ブックマークが存続する限りずっと変更されません．
スナップショットが別のプールに送信されると，受信したスナップショットは同じ GUID を持ちます．
したがって，guid はプール全体のスナップショットを識別するのに適しています．

primarycache

値は all，none，metadata になります．

プライマリキャッシュ (ARC) に何をキャッシュするかを制御します．
このプロパティが all に設定されている場合，ユーザーデータとメタデータの両方がキャッシュされます．
このプロパティが none に設定されている場合，ユーザーデータもメタデータもキャッシュされません．
このプロパティが metadata に設定されている場合，メタデータのみがキャッシュされます．
デフォルト値は「all」です．

secondarycache

値は all，none，metadata になります．

二次キャッシュ (L2ARC) に何をキャッシュするかを制御します．
このプロパティが all に設定されている場合，ユーザーデータとメタデータの両方がキャッシュされます．
このプロパティが none に設定されている場合，ユーザーデータもメタデータもキャッシュされません．
このプロパティが metadata に設定されている場合，メタデータのみがキャッシュされます．
デフォルト値は「all」です．

usedbysnapshots

このデータセットのスナップショットによって消費されているスペースの量．
特に，このデータセットのスナップショットがすべて破棄された場合に解放されるスペースの量です．
領域は複数のスナップショットで共有される可能性があるため，これはスナップショットの使用済みプロパティの単純な合計ではないことに注意してください．

usedbydataset

このデータセット自体によって使用されるスペースの量．
データセットが破棄された場合に解放される量になります．

usedbychildren

このデータセットの配下によって使用されるスペースの量．
データセットのすべての子が破棄された場合に解放される量になります．

usedbyrefreservation

このデータセット上の refreservation セットによって使用されるスペースの量．
refreservation が削除された場合に解放される量になります．

logbias

値は latency，throughput です．

このデータセット内の同期リクエストの処理に関するヒントを ZFS に提供します．
logbias が latency (デフォルト) に設定されている場合，ZFS はプールログデバイス (構成されている場合) を使用して低遅延でリクエストを処理します．
logbias が throughput に設定されている場合，ZFS は構成されたプールログデバイスを使用しません．
ZFS は代わりに，グローバルプールの throughput とリソースの効率的な使用のために同期操作を最適化します．

objsetid

プール内のこのデータセットの一意の識別子．
データセットの guid とは異なり，send/recv でスナップショットがコピーされる際，データセットの objsetid は他のプールに転送されません．
objsetid は，データセットの削除後に (新しいデータセット用に) 再利用されます．

dedup

値は off，on，verify，sha256，sha256,verify，sha512，sha512,verify，skein，skein,verify，edonr,verify，blake3，blake3,verify です．

データセットの重複排除を構成します．
デフォルト値は off です．現在のデフォルトの重複排除チェックサムは sha256 です．
重複排除が有効な場合，ここで定義されたチェックサムは checksum プロパティを上書きします． verify に設定すると，現在は sha256,verify の設定と同じ効果があります．
verify に設定すると，ZFS は 2 つのブロックが同じ署名を持つ場合にバイト間比較を実行して，ブロックの内容を同一か確認します．
edonr アルゴリズムでは verify の指定が必須です．

mlslabel

mlslabel プロパティは、現在 FreeBSD でサポートされていません。

sync

値は standard，always，disabled です．

同期リクエスト (fsync、O_DSYNC など) の動作を制御します．
standard は，すべての同期リクエストがストレージに書き込まれ，データがデバイスコントローラーによってキャッシュされないようにすべてのデバイスがフラッシュされることを保証する POSIX 指定の動作です (これがデフォルトです)．

always は，すべてのファイルシステムトランザクションが書き込まれ，フラッシュされた後システムコールを返します．これにはパフォーマンスに大きなペナルティが伴います．

disabled は同期リクエストを無効にします．ファイルシステムトランザクションは，ストレージに定期的にのみコミットされます．このオプションでは最高のパフォーマンスが得られます．
ただし，ZFS はデータベースや NFS などのアプリケーションの同期トランザクション要求を無視することになるため，非常に危険です．
管理者は，リスクを理解している場合にのみこのオプションを使用してください．

dnodesize

値は legacy，auto，1k，2k，4k，8k，16k です．

ファイルシステム内の dnode のサイズの互換モードまたはリテラル値を指定します．
デフォルト値はレガシーです．このプロパティをレガシー以外の値に設定するには，プールでlarge_dnode を有効にする必要があります．

データセットで xattr=sa プロパティ設定が使用されており，ワークロードで拡張属性が頻繁に使用される場合は、dnodesize を auto に設定することを検討してください．
これは、SELinux 対応システム，Lustre サーバー，Samba サーバーなどに適用できる場合があります．
リテラル値は，最適なサイズが事前にわかっている場合とパフォーマンステストのためにサポートされます．

large_dnode 機能が有効になっていないプールでこのデータセットの送信ストリームを受信する必要がある場合，またはlarge_dnode 機能をサポートしていないシステムにこのプールをインポートする必要がある場合は，dnodesize をレガシーに設定したままにしてください．

このプロパティは，短縮された列名 dnsize によって参照することもできます．

refcompressratio

このデータセットの参照空間に対して達成された圧縮率です．乗数として表されます．
compressratio プロパティも参照してください．

以上，長くなったので次回へ続きます．

FreeBSD で ZFS を利用する – ZFS ファイルシステムの機能について理解する (2)

seichan — Mon, 01 Jan 2024 13:00:00 +0000

ZFS に関するお話

ZFS ファイルシステムプロパティ

作成済みの ZFS ファイルシステムのプロパティを表示するとこのように沢山の項目が表示されます．

# zfs get all pool0
NAME   PROPERTY              VALUE                  SOURCE
pool0  type                  filesystem             -
pool0  creation              Mon Dec 18 18:35 2023  -
pool0  used                  10.0G                  -
pool0  available             375G                   -
pool0  referenced            32.0K                  -
pool0  compressratio         1.00x                  -
pool0  mounted               yes                    -
pool0  quota                 none                   default
pool0  reservation           none                   default
pool0  recordsize            128K                   default
pool0  mountpoint            /pool0                 default
pool0  sharenfs              off                    default
pool0  checksum              on                     default
pool0  compression           off                    default
pool0  atime                 on                     default
pool0  devices               on                     default
pool0  exec                  on                     default
pool0  setuid                on                     default
pool0  readonly              off                    default
pool0  jailed                off                    default
pool0  snapdir               hidden                 default
pool0  aclmode               discard                default
pool0  aclinherit            restricted             default
pool0  createtxg             1                      -
pool0  canmount              on                     default
pool0  xattr                 on                     default
pool0  copies                1                      default
pool0  version               5                      -
pool0  utf8only              off                    -
pool0  normalization         none                   -
pool0  casesensitivity       sensitive              -
pool0  vscan                 off                    default
pool0  nbmand                off                    default
pool0  sharesmb              off                    default
pool0  refquota              none                   default
pool0  refreservation        none                   default
pool0  guid                  1264596009273225631    -
pool0  primarycache          all                    default
pool0  secondarycache        all                    default
pool0  usedbysnapshots       0B                     -
pool0  usedbydataset         32.0K                  -
pool0  usedbychildren        10.0G                  -
pool0  usedbyrefreservation  0B                     -
pool0  logbias               latency                default
pool0  objsetid              54                     -
pool0  dedup                 off                    default
pool0  mlslabel              none                   default
pool0  sync                  standard               default
pool0  dnodesize             legacy                 default
pool0  refcompressratio      1.00x                  -
pool0  written               32.0K                  -
pool0  logicalused           206K                   -
pool0  logicalreferenced     12.5K                  -
pool0  volmode               default                default
pool0  filesystem_limit      none                   default
pool0  snapshot_limit        none                   default
pool0  filesystem_count      none                   default
pool0  snapshot_count        none                   default
pool0  snapdev               hidden                 default
pool0  acltype               nfsv4                  default
pool0  context               none                   default
pool0  fscontext             none                   default
pool0  defcontext            none                   default
pool0  rootcontext           none                   default
pool0  relatime              off                    default
pool0  redundant_metadata    all                    default
pool0  overlay               on                     default
pool0  encryption            off                    default
pool0  keylocation           none                   default
pool0  keyformat             none                   default
pool0  pbkdf2iters           0                      default
pool0  special_small_blocks  0                      default

自分で設定が変えられる項目，変えられない項目がありますが，以下この並びに沿って解説を入れていきます．
前回は compression まで記載しましたので，今回はその続きになります．

atime

値は on，off になります．

ファイルの読み取り時にファイルのアクセス時間を更新するかどうかを制御します．
このプロパティを off にすると，ファイルの読み取り時に書き込みが発生しなくなるため，パフォーマンスが大きく向上する可能性がありますが，アプリケーションなどで不具合が生じる可能性があります．
on および off の値は、マウントオプションの atime および noatime と同等です．
デフォルト値はオンです。以下の「relatime」も参照してください．

devices

値は on，off になります．

このファイルシステム上でデバイスノードを開くことができるかどうかを制御します．
デフォルト値は on です．
on および off の値は，マウントオプションの dev および nodev と同等です．

exec

値は on，off になります．

このファイルシステム内からプロセスを実行できるかどうかを制御します．
デフォルト値は on です．
on および off の値は，マウントオプションの exec および noexec と同等です．

setuid

値は on，off になります．

ファイルシステムに対して setuid ビットを利用可能にするかどうかを制御します．
デフォルト値は on です．
on および off の値は、マウントオプション suid および nosuid と同等です．

readonly

値は on，off になります．

データセットを変更できるかどうかを制御します．
on に設定すると，データを変更できなくなります．

jailed

値は on，off になります．

データセットが jail の内部から管理されるかどうかを制御します．
詳細については，「jail」セクションを参照してください．
デフォルト値は off です．

snapdir

値は hidden または visible になります．

.zfs ディレクトリを表示させるかどうかを制御します．hidden の場合は表示されません (アクセスすることは可能です)
デフォルト値は hidden です．

aclmode

値は discard，groupmask，passthrough，restricted です．

chmod(2) 中に ACL がどのように変更されるか，また，継承された ACE がファイル作成モードによってどのように変更されるかを制御します．

discard

デフォルト値．chmod(2) によって要求されたファイルまたはディレクトリのモードを表す ACE を除くすべての ACE を削除します．

groupmask

ACL 内で見つかったすべての ALLOW エントリで付与される権限を，chmod(2) で指定されたグループ権限を超えないように削減します．

passthrough

ファイルまたはディレクトリの新しいモードを表すために必要な ACL エントリの作成または更新以外に、ACL に変更が加えられないことを示します．

restricted

モードでエントリを表現できない重要な ACL を持つファイルまたはディレクトリに対して chmod(2) 操作を使用すると，エラーが返されます．
chmod(2) は，ファイルまたはディレクトリ上の設定されたユーザー ID，設定されたグループ ID，またはスティッキービットを変更するために必要です．これらのビットには同等の ACL エントリがないためです．
aclmode が制限付きに設定されているときに，重要な ACL を持つファイルまたはディレクトリに対して chmod(2) を使用するには，まず現在のモードを表さないすべての ACL エントリを削除する必要があります．

aclinherit

値は discard，noallow，restricted，passthrough，passthrough-x です．

ファイルとディレクトリの作成時に ACE がどのように継承されるかを制御します。

discard

ACE を継承しません．

noallow

「拒否」権限を指定する継承可能な ACE のみを継承します．

restricted

デフォルト値です．ACE が継承されるときに write_acl および write_owner 権限が削除されます．

passthrough

継承可能なすべての ACE を変更せずに継承します．

passthrough-x

パススルーと同じ意味ですが，owner@，group@，Everyone@ ACE は，ファイル作成モードが実行ビットも要求する場合にのみ実行権限を継承します．

プロパティ値がパススルーに設定されている場合，ファイルは継承可能な ACE によって決定されるモードで作成されます．
モードに影響を与える継承可能な ACE が存在しない場合，アプリケーションから要求されたモードに従ってモードが設定されます．

aclinherit プロパティは POSIX ACL には適用されません．

createtxg

値は on，off，オプションになります．

データセットが作成されたトランザクショングループ (txg)です．
ブックマークには，最初に関連付けられているスナップショットと同じ createtxg が設定されています．
このプロパティは，スナップショットのリストを並べ替えるのに適しています．

canmount

値は on，off，noauto です．

このプロパティが off に設定された場合，ファイルシステムをマウントすることができず，“zfs mount -a” は無視されます．
このプロパティを off に設定することは，データセットからみて継承することができる通常の mountpoint プロパティがまだあることを除いて、 mountpoint プロパティを none に設定することと同様です。
このプロパティを off 設定することによって，データセットをプロパティを継承するための唯一メカニズムとして使用することができます．
canmount=off を設定する一例として，両方のデータセットの子供が同じディレクトリに現れることができように、同じ mountpoint がある 2 つのデータセットがあることですが、異なっで継承される特性 (characteristic) があるかもしれません．
noauto の値が設定された場合，明示的にデータセットをマウント，アンマウントすることができます．
データセットは，自動的にマウントされず，“zfs mount -a” コマンドでもマウントされません．また，“zfs umount -a” コマンドでアンマウントされることもありません．

xattr

値はon，off，sa です．

このファイルシステムに対して拡張属性を有効にするかどうかを制御します．
ディレクトリベースまたはシステム属性ベースの二つのスタイルの拡張属性がサポートされています．

デフォルト値の on では，ディレクトリベースの拡張属性が有効になります．
このスタイルの拡張属性では，ファイルに設定できる属性のサイズや数に実際的な制限はありません．
ただし，Linux では getxattr(2) および setxattr(2) システムコールにより最大サイズが 64K に制限されます．
これは拡張属性の最も互換性のあるスタイルであり，すべての ZFS 実装でサポートされています．

システム属性ベースの xattrs は，値を sa に設定することで有効にできます．
このタイプの xattr の主な利点はパフォーマンスの向上です．
拡張属性をシステム属性として保存すると必要なディスク I/O の量が大幅に減少します．
システム属性用に予約されたスペースには，ファイルごとに最大 64K のデータを保存できます．
拡張属性に使用できる十分なスペースがない場合，拡張属性はディレクトリベースの xattr として自動的に書き込まれます．
システム属性ベースの拡張属性は，xattr=sa 機能をサポートしていないプラットフォームではアクセスできません．
OpenZFS は，FreeBSD と Linux の両方で xattr=sa をサポートします．

SELinux または POSIX ACL のユーザーには，システム属性ベースの xattrs の使用が強く推奨されます．
これらの機能はどちらも拡張属性に大きく依存しており，アクセス時間の短縮によって大きなメリットが得られます．

on および off は，マウントオプションの xattr および noxattr と同等です．

copies

値は 1，2，3 です．

このデータセットに保存されるデータのコピーの数を制御します．
これらのコピーは，ミラーリングや RAID-Z など，プールによって提供される冗長性に追加されます．
可能であれば，コピーは別のディスクに保存されます．
複数のコピーによって使用されるスペースは，関連付けられたファイルとデータセットにチャージされ，使用されるプロパティが変更され，クォータと予約に対しても影響されます．
このプロパティを変更すると，新しく書き込まれたデータにのみ影響します．
したがって，最初からコピー数を制御したい場合はファイルシステムの作成時に「-ocopies=N」オプションを使用してこのプロパティを設定します．

ZFS は，最上位の vdev が欠落しているプールはインポートできないことに注意してください．
たとえば，冗長性が設定されていると考えて，一部のデータセットに 2 つのディスクのストライププールを作成し，copys=2 を設定しないでください．
ディスクに障害が発生すると，プールをインポートできなくなりすべてのデータが失われます．

実装では通常 3 番目のコピーが存在する場所に一部の暗号化メタデータが保存されるため，暗号化されたデータセットには「copy=3」が存在しない場合があります．
このプロパティのデフォルト値は「1」です．

utf8only

値は on，off です．

デフォルト値は off です．
UTF-8 文字コードセットに存在しない文字を含むファイル名をファイルシステムが拒否するかどうかを示します．
このプロパティが明示的にオフに設定されている場合は，正規化プロパティを明示的に設定しないか，または none に設定する必要があります．
utf8only プロパティのデフォルト値はオフです．
このプロパティは，ファイルシステムの作成後に変更することはできません．

normalization

値は none，formC，formD，formKC，formKD です．

デフォルト値は none です．
二つのファイル名を比較するときにファイルシステムがファイル名の Unicode 正規化を実行するかどうか，およびどの正規化アルゴリズムを使用するかを示します．
ファイル名は常に変更されずに保存され，名前は比較プロセスの一部として正規化されます．
このプロパティが none 以外の有効な値に設定され，utf8only プロパティが指定されていない場合，utf8only プロパティは自動的に on に設定されます．
このプロパティは，ファイルシステムの作成後に変更することはできません．

casesensitivity

値は sensitive，insensitive，mixed です．

ファイルシステムで使用されるファイル名一致アルゴリズムが「大文字と小文字を区別する」か「大文字と小文字を区別しない」か，または両方の形式の一致の組み合わせを許可するかを示します．
デフォルト値は sensitive で，大文字と小文字を区別します．
従来，Unix および POSIX ファイルシステムでは、「大文字と小文字が区別される」ファイル名が使用されていました．

casesensitivity プロパティの mixed は，ファイルシステムが「大文字と小文字を区別する」と「大文字と小文字を区別しない」の両方の要求をサポートできることを示します．
現在，mixed をサポートするファイルシステムでの大文字と小文字を区別しない一致動作は，SMB サーバー製品に限定されています．
mixed 値の動作の詳細については『ZFS Administration Guide』を参照してください．

以上，長くなったので次回へ続きます．

FreeBSD で ZFS を利用する – ZFS ファイルシステムの機能について理解する (1)

seichan — Sun, 31 Dec 2023 13:00:00 +0000

ZFS に関するお話

ZFS ファイルシステムプロパティ

ZFS ファイルシステムプロパティ

作成済みの ZFS ファイルシステムのプロパティを表示するとこのように沢山の項目が表示されます．

# zfs get all pool0
NAME   PROPERTY              VALUE                  SOURCE
pool0  type                  filesystem             -
pool0  creation              Mon Dec 18 18:35 2023  -
pool0  used                  10.0G                  -
pool0  available             375G                   -
pool0  referenced            32.0K                  -
pool0  compressratio         1.00x                  -
pool0  mounted               yes                    -
pool0  quota                 none                   default
pool0  reservation           none                   default
pool0  recordsize            128K                   default
pool0  mountpoint            /pool0                 default
pool0  sharenfs              off                    default
pool0  checksum              on                     default
pool0  compression           off                    default
pool0  atime                 on                     default
pool0  devices               on                     default
pool0  exec                  on                     default
pool0  setuid                on                     default
pool0  readonly              off                    default
pool0  jailed                off                    default
pool0  snapdir               hidden                 default
pool0  aclmode               discard                default
pool0  aclinherit            restricted             default
pool0  createtxg             1                      -
pool0  canmount              on                     default
pool0  xattr                 on                     default
pool0  copies                1                      default
pool0  version               5                      -
pool0  utf8only              off                    -
pool0  normalization         none                   -
pool0  casesensitivity       sensitive              -
pool0  vscan                 off                    default
pool0  nbmand                off                    default
pool0  sharesmb              off                    default
pool0  refquota              none                   default
pool0  refreservation        none                   default
pool0  guid                  1264596009273225631    -
pool0  primarycache          all                    default
pool0  secondarycache        all                    default
pool0  usedbysnapshots       0B                     -
pool0  usedbydataset         32.0K                  -
pool0  usedbychildren        10.0G                  -
pool0  usedbyrefreservation  0B                     -
pool0  logbias               latency                default
pool0  objsetid              54                     -
pool0  dedup                 off                    default
pool0  mlslabel              none                   default
pool0  sync                  standard               default
pool0  dnodesize             legacy                 default
pool0  refcompressratio      1.00x                  -
pool0  written               32.0K                  -
pool0  logicalused           206K                   -
pool0  logicalreferenced     12.5K                  -
pool0  volmode               default                default
pool0  filesystem_limit      none                   default
pool0  snapshot_limit        none                   default
pool0  filesystem_count      none                   default
pool0  snapshot_count        none                   default
pool0  snapdev               hidden                 default
pool0  acltype               nfsv4                  default
pool0  context               none                   default
pool0  fscontext             none                   default
pool0  defcontext            none                   default
pool0  rootcontext           none                   default
pool0  relatime              off                    default
pool0  redundant_metadata    all                    default
pool0  overlay               on                     default
pool0  encryption            off                    default
pool0  keylocation           none                   default
pool0  keyformat             none                   default
pool0  pbkdf2iters           0                      default
pool0  special_small_blocks  0                      default

自分で設定が変えられる項目，変えられない項目がありますが，以下この並びに沿って解説を入れていきます．

filesystem

値は filesystem，volume，snapshot，bookmark になります．
ここの値は zfs create で作成した種類が表示される項目になります．

used

このデータセットとそのすべての配下のファイルシステムによって消費されている使用量です．
これは，データセットの割り当てと予約に対して反映される値となります．
used で表示される使用量には，このデータセット自身の予約は含まれませんが，配下のデータセットの予約は考慮されます．

スナップショットの場合，使用済みスペース (zfsconcepts(7) の「スナップショット」セクションを参照) は、このスナップショットによって生じた差分が表示されます．
スナップショットが破棄されると，使用されていた領域が解放されます．

used，available，referenced で表示される領域は保留中の変更は考慮されません．
保留中の変更は通常は数秒以内に反映されます．
fsync(2) または O_SYNC を使用してディスクに変更をコミットしても，スペース使用量情報がすぐに更新されることが保証されるわけではありません．

available

プール内に他の影響要素がないことを前提とした，データセットとその配下のデータセットが利用できる空き領域の容量です．
スペースはプール内で共有されるため，プールサイズ，クォータ，予約，プール内のその他のデータセットなど，さまざまな要因によって空き容量が変化・制限される可能性があります．

このプロパティは，短縮された列名 avail によって参照することもできます．

referenced

このデータセットが参照されているデータの量です．
プール内の他のデータセットと共有される場合と共有されない場合があります．
スナップショットまたはクローンが作成されると，その内容は同一であるため，最初は作成元のファイルシステムまたはスナップショットと同じ量のスペースを参照します．

compressratio

このデータセットの使用スペースに対して反映されている圧縮率が乗数で表示されます．
使用されるプロパティには配下のデータセットが含まれますが，クローンの場合は元のスナップショットと共有されるスペースは含まれません．
スナップショットの場合，圧縮率は refcompressratio プロパティと同じになります．

圧縮は，zfs set compression=on を実行することで有効ににできます．compression のデフォルト値は off です．

mounted

ファイルシステムの場合，ファイルシステムが現在マウントされているかどうかを表しています．
このプロパティは，yes または no のいずれかになります．

quota

値は size または none になります．

データセットとその配下が利用できる領域を制限します．
このプロパティは，使用できる領域に厳しい制限を適用します．
これには，ファイルシステムやスナップショットなど，配下で消費されるすべての領域が含まれます．
すでにクォータが設定されているデータセットの配下にクォータを設定した場合，上位のクォータは上書きされず，配下のデータセットに追加の制限が課されます．

reservation

値は size または none になります．

データセットとその配下に対して保証される最小領域を設定できます．
使用されているデータ量がこの値を下回っている場合，データセットは予約で指定された領域を占有しているかのように扱われます．
予約は，親データセットの使用領域で考慮され，親データセットのクォータと予約に対してカウントされます．

このプロパティは，短縮された列名 reserv によって参照することもできます．

recordsize

値は size です．

ファイルシステム内のファイルの推奨ブロックサイズを指定します．
このプロパティは，固定サイズのレコード内のファイルにアクセスするデータベースワークロードでのみ使用するように設計されています．
ZFS は，一般的なアクセスパターンに最適化された内部アルゴリズムに従ってブロックサイズを自動的に調整します．

データベースなどで非常に大きなファイルを作成するけど，それらのファイルにランダムな小さな塊でアクセスする場合，これらのアルゴリズムは最適ではない可能性があります．
データベースのレコードサイズ以上のレコードサイズを指定すると，パフォーマンスが大幅に向上する可能性があります．
このプロパティを汎用的なファイルシステムに使用することは推奨しません．パフォーマンスに悪影響を与える可能性があります．

指定するサイズは，512 B 以上 128 KiB 以下の 2 のべき乗である必要があります．
プールで large_blocks 機能が有効になっている場合，1MiB まで設定することが可能です．
ZFS 機能フラグの詳細については，zpool-features(7) を参照してください．

ファイルシステムのレコードサイズを変更すると，それ以降に作成されたファイルにのみ影響し，既存のファイルは影響を受けません．

このプロパティは，短縮された列名 recsize によって参照することもできます．

mountpoint

値は path，none，legacy です．

ファイルシステムに使用されるマウントポイントを制御します．このプロパティの使用方法の詳細については，zfsconcepts(7) の「mountpoint」セクションを参照してください．

ファイルシステムのマウントポイントプロパティが変更されると，ファイルシステムとマウントポイントを継承するすべての配下のデータセットがアンマウントされます．
新しい値が legacy の場合，それらはアンマウントされたままになります．
それ以外の場合やプロパティが以前 legacy であった場合，またはプロパティが none だった場合は，新しい場所に自動的に再マウントされます．
さらに，共有ファイルシステムは共有解除されて新しい場所で共有されます．

mountpoint プロパティを zfs set -u で設定すると，マウントポイントプロパティは更新されますが，データセットはマウントまたはアンマウントされずに以前の状態のままになります．

sharenfs

値は on，off，オプションになります．

ファイルシステムを NFS 経由で共有するかどうか，およびどのオプションを使用するかを制御します．

sharenfs プロパティーが off のファイルシステムで NFS 共有を行う場合は exportfs(8) コマンドと /etc/exports ファイル内のエントリーを使用して管理されます．
それ以外の場合，ファイルシステムは zfs share および zfs unshare コマンドを使用して自動的に共有および共有解除されます．
このプロパティが on に設定されている場合，データセットはデフォルトのオプション「sec=sys,rw,crossmnt,no_subtree_check」を使用して共有されます．

オプションは，exports(5) にあるオプションとは異なり，カンマで区切られていることに注意してください．これは，引用符の必要性をなくし，スクリプトによる解析を容易にするために行われます．

オプションの意味については，exports(5) を参照してください．

データセットの sharenfs プロパティが変更されると，そのプロパティが以前 off であった場合，またはプロパティが変更される前に共有されていた場合に限り，データセットとプロパティを継承するすべての配下が新しいオプションで再共有されます．
新しいプロパティが off の場合，ファイルシステムの共有は解除されます．

sharenfs プロパティを zfs set -u で更新すると，プロパティは目的の値に設定されますが，データセットを共有，再共有，または共有解除する操作は実行されません．

checksum

値は on，off，fletcher2，fletcher4，sha256，noparity，sha512，skein，edonr です．

データの整合性を検証するために使用されるチェックサムを制御します．
デフォルト値は on で、適切なアルゴリズム (現在は fletcher4) が自動的に選択されます．

off にすると，ユーザーデータの整合性チェックを無効にします．

noparity は，整合性を無効にするだけではなく，ユーザーデータのパリティの維持も無効にします．

チェックサムを無効にすることはお勧めできません．

sha512，skein，edonr チェックサムアルゴリズムでは，プールで適切な機能を有効にする必要があります．
また，現在 FreeBSD は edonr アルゴリズムをサポートしていません．

これらのアルゴリズムの詳細については，zpool-features(7) を参照してください．
このプロパティを変更すると，新しく書き込まれたデータのみが影響を受けます．

compression

値は on，off，gzip，gzip-N，lz4，lzjb，zle，zstd，zstd-N，zstd-fast，zstd-fast-N です．

データセットに使用される圧縮アルゴリズムを制御します．

圧縮を on に設定すると，現在のデフォルトの圧縮アルゴリズム (lzjb または lz4_compress が有効な場合は lz4) が使用されます．
デフォルトでは，圧縮率と圧縮速度と解凍速度のバランスが取れており，さまざまなワークロードで適切に動作すると予想されます．
このプロパティの他のすべての設定とは異なり，on では固定圧縮タイプが選択されません．
新しい圧縮アルゴリズムが ZFS に追加され，プールで有効になると，デフォルトの圧縮アルゴリズムが変更される可能性があります．
(したがって，on ではなく明示的にアルゴリズムを指定することを推奨します)

lz4 圧縮アルゴリズムは、lzjb アルゴリズムに代わる高性能なアルゴリズムです．
lzjb よりも大幅に高速な圧縮と圧縮解除，および適度に高い圧縮率を備えています．
lz4_compress 機能が有効に設定されているプールでのみ使用できます．
ZFS 機能フラグと lz4_compress 機能の詳細については，zpool-features(7) を参照してください

lzjb 圧縮アルゴリズムは，適切なデータ圧縮を提供しながらパフォーマンスが最適化されています

gzip 圧縮アルゴリズムは，gzip(1) コマンドと同じ圧縮を使用します．
gzip レベルは，値 gzip-N を使用して指定できます．N は 1 (最速) から 9 (最高の圧縮率) までの整数です．
現在，gzip を選択すると gzip-6 を設定した事と同義となります．

zstd 圧縮アルゴリズムは，高い圧縮率と優れたパフォーマンスの両方を提供します．
zstd-N を使用して zstd レベルを指定できます．N は 1 (最速) から 19 (最高の圧縮率) までの整数です．
zstd を選択した場合，zstd-3 を指定したのと同義となります．

マイナスの zstd レベルを設定すると，圧縮率を犠牲にして高速化を要求できます．
これは，zstd-fast-N を使用して行われます。N は，マイナスの zstd レベルにマッピングされる [1-9,10,20,30,…,100,500,1000] の整数です．
レベルが低いほど圧縮速度が速くなります．-1000 は最も速い圧縮と最も低い圧縮率を提供します．
zstd-fast を設定した場合，zstd-fast-1 と同義です．

zle 圧縮アルゴリズムは，ゼロの連続を圧縮します．

このプロパティは，短縮された列名 compress によって参照することもできます．
このプロパティを変更すると，新しく書き込まれたデータのみが影響を受けます．

圧縮されるブロックは，圧縮後の元のサイズの 7/8 以下にならない場合，圧縮する価値があるとみなされず，ブロックは圧縮されずに保存されます．
論理ブロックがディスクセクターサイズの 8 倍未満の場合，必要な圧縮率が効果的に低下することに注意してください．
たとえば，4kB ディスクセクターを持つディスク上の 8kB ブロックは，元のサイズの 1/2 以下に圧縮する必要があります．

以上，長くなったので次回へ続きます．

FreeBSD で ZFS を利用する – 重複排除を利用する・確認する

seichan — Wed, 27 Dec 2023 13:00:00 +0000

今回は ZFS の大きな特徴の一つである，重複排除にフォーカスしたいと思います．
ZFS はファイルシステム (ZVOLも) の重複排除が利用できます．
これによってストレージ利用量の削減が見込めます．

ZFS に関するお話

重複排除とは
1. 重複排除の有効化
2. 重複排除の効果
重複排除と圧縮の両方を有効にする
1. 重複排除と圧縮の効果
大事な注意点

重複排除とは

重複排除は，同一のデータが複数あった場合，ストレージ上には一つのデータのみを保持し，各データへのポインターを持つことでストレージ容量の節約をはかる技術です．

以下の図としては同じファイルが複数のフォルダーにあるイメージですが，実際としてはファイルの比較ではなく，ファイル内のデータを比較して重複排除の対象となります．

重複排除の有効化

ZFS の重複排除の有効化はファイルシステム/ZVOL 単位で zfs set で実施可能です．
以下は新規のファイルシステムを作成，そのファイルシステムに重複排除を有効化させる手順となります．

# zfs create pool0/dedup

# zfs set dedup=on pool0/dedup

# zfs get dedup pool0/dedup
NAME         PROPERTY  VALUE          SOURCE
pool0/dedup  dedup     on             local

重複排除の効果

重複排除の効果を測定するため，圧縮の際と同様に FreeBSD のソースコードを展開して状況を見てみたいと思います．
/pool0/dedup が作成されましたのでサブディレクトリーを作成して，その中にソースコードを展開し，使用量や重複排除の結果を確認してみます．

# mkdir /pool0/dedup/src1
# cd /pool0/dedup/src1
# tar jxf /root/src_stable_13.tar.xz

# df -H /pool0/dedup
Filesystem     Size    Used   Avail Capacity  Mounted on
pool0/dedup    412G    1.4G    410G     0%    /pool0/dedup

df の結果は本来の使用量が表示されます．重複排除の状態を確認するには zpool list コマンドを用いて確認となります．

# zpool list pool0
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
pool0   596G  2.02G   594G        -         -     0%     0%  1.01x    ONLINE  -

1.01x が現状の効果となり，ソースコードを1回展開した場合は 1% 程重複排除が効いている状態となります．

もう一度ソースコードを展開して，再度状況を確認してみます．

# mkdir /pool0/dedup/src2
# cd /pool0/dedup/src2
# tar jxf /root/src_stable_13.tar.xz

# df -H /pool0/dedup
Filesystem     Size    Used   Avail Capacity  Mounted on
pool0/dedup    413G    2.9G    410G     1%    /pool0/dedup

# zpool list pool0
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
pool0   596G  2.08G   594G        -         -     0%     0%  2.02x    ONLINE  -

いかがでしょうか．2.02x となり，まるっと重複排除対象として扱われている事が判ります．1.4GB 程展開してデータは増えていますが，FREE の値に変化がないためしっかりと効いている事が確認できます．

重複排除と圧縮の両方を有効にする

重複排除と圧縮は排他ではなく，両方を有効にすることができます．
ZSTD も有効にした形でどのような効果があるかを確認してみます．

# zfs create pool0/dedup-zstd

# zfs set dedup=on pool0/dedup-zstd
# zfs set compression=zstd pool0/dedup-zstd

# zfs get dedup pool0/dedup-zstd
NAME              PROPERTY  VALUE          SOURCE
pool0/dedup-zstd  dedup     on             local

# zfs get compression pool0/dedup-zstd
NAME              PROPERTY     VALUE           SOURCE
pool0/dedup-zstd  compression  zstd            local

重複排除と圧縮の効果

重複排除と圧縮の効果を測定するため，先ほどと同様に FreeBSD のソースコードを展開して状況を見てみたいと思います．
/pool0/dedup-zstd が作成されましたのでサブディレクトリーを作成して，その中にソースコードを展開し，使用量や重複排除の結果を確認してみます．

# mkdir /pool0/dedup-zstd/src1
# cd /pool0/dedup-zstd/src1
# tar jxf /root/src_stable_13.tar.xz

# df -H /pool0/dedup-zstd/src1
Filesystem          Size    Used   Avail Capacity  Mounted on
pool0/dedup-zstd    410G    444M    410G     0%    /pool0/dedup-zstd

Used が先が 1.4G で今回が 444M ですので，まず圧縮が効いている事が確認できます．
zfs get と zpool list で ZFS としてどのように見えているのかを確認します．

# zfs get compressratio pool0/dedup-zstd
NAME              PROPERTY       VALUE  SOURCE
pool0/dedup-zstd  compressratio  3.44x  -

# zpool list pool0
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
pool0   596G  2.79G   593G        -         -     0%     0%  1.01x    ONLINE  -

圧縮が行われつつ，重複排除も効いている事が確認できました．
追加でソースコードを展開して変化を見てみます．

# mkdir /pool0/dedup-zstd/src2
# cd /pool0/dedup-zstd/src2
# tar jxf /root/src_stable_13.tar.xz

# df -H /pool0/dedup-zstd/src1
Filesystem          Size    Used   Avail Capacity  Mounted on
pool0/dedup-zstd    412G    889M    411G     0%    /pool0/dedup-zstd

# zpool list pool0
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
pool0   596G   758M   595G        -         -     0%     0%  2.03x    ONLINE  -

圧縮が効いているため，444M が二つ分となっています．
DEDUP が 2.03x ですのでまるっと重複排除対象になっています．また，圧縮が効いている効果で FREE の値が2回目が増えている状況です．

このように，両方を有効にすることでよりストレージの使用量を節約する事が可能です．

大事な注意点

このように非常に効果が見込まれる重複排除ですが，メモリーを大量に必要とする点を注意する必要があります．
大まかにですが，1TB の領域あたり，1GB のメモリーを使用します．これが不足する状況だとパフォーマンスが大きく劣化する事や重複排除自体の障害を引き起こす可能性があります．

したがって，4TB の領域がある場合，ARC の容量も含めてで ZFS に対して 8GB 程のメモリーを搭載している事が望ましいと考えられます．

実利用にあたっては，よくテストを行ったうえで利用する事をお勧めします．
実際に筆者環境においてはメモリー不足でトラブルとなった為頑張って無効のファイルシステムにデータを移行した経緯があります…
今はメモリーも十分なファイルサーバーとなったので改めて利用チャレンジを考えている所です．

以上，ZFS の重複排除の紹介でした．

FreeBSD で ZFS を利用する – キャッシュを構成・設定する

seichan — Mon, 25 Dec 2023 13:00:00 +0000

今回は「FreeBSD で ZFS を利用する – ZFS のキャッシュの仕組みを理解する」で説明した ARC の設定，L2ARC および SLOG デバイスの構成を実施します．

ZFS に関するお話

ARC の設定
L2ARC の設定
SLOG の設定
利用状況を確認する
1. zfs iostat で確認する
2. zfs-stats パッケージを利用する
  1. zfs-mon
  2. zfs-stats

ARC の設定

ARC はデフォルトで搭載メモリ -1G が最大値となっています．ですので，他のサービスを動作させようとする場合，ARC にメモリが持っていかれて他サービス側に影響を及ぼすことがあります．

したがって，ARC に割り当てる最大値を明示的に設定する事をお勧めします．

sysctl の該当のノブ名およびデフォルトの値は次のとおりです．

# sysctl vfs.zfs.arc_max
vfs.zfs.arc_max: 0

最大値を設定する際，バイト単位で値を入力します．昔は M などの単位も使えたのですが今は次のとおりの結果となります．例は3G を最大値に指定しようとした場合です．

# sysctl vfs.zfs.arc_max=3072M
sysctl: invalid unsigned long '3072M'

ですので，バイト単位の値で設定する必要があります．3G をバイトになおすと 3221225472 ですので，これで設定してみます．

# sysctl vfs.zfs.arc_max=3221225472
vfs.zfs.arc_max: 0 -> 3221225472

この通り，0 から値が変更されました．

再起動後も設定を反映させるために /boot/loader.conf にも追記しましょう．

# cat /boot/loader.conf
vfs.zfs.arc_max=3221225472

L2ARC の設定

SSD/NVMe デバイスを L2ARC として設定したい場合，方法は二通りあります．プールの作成時に指定するか後から追加するかです．結果に違いはありません．

今回はすでにあるプール pool0 に対して L2ARC を追加してみます．わかりやすさで NVMe デバイスを搭載，指定しています．

まずは現状のプールの状態を確認します．

# zpool status pool0
  pool: pool0
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        pool0       ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            da1     ONLINE       0     0     0
            da2     ONLINE       0     0     0
            da3     ONLINE       0     0     0
          raidz1-1  ONLINE       0     0     0
            da4     ONLINE       0     0     0
            da5     ONLINE       0     0     0
            da6     ONLINE       0     0     0

errors: No known data errors

これに L2ARC のキャッシュデバイスを追加してステータスを確認します．

# zpool add pool0 cache nvd0

# zpool status pool0
  pool: pool0
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        pool0       ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            da1     ONLINE       0     0     0
            da2     ONLINE       0     0     0
            da3     ONLINE       0     0     0
          raidz1-1  ONLINE       0     0     0
            da4     ONLINE       0     0     0
            da5     ONLINE       0     0     0
            da6     ONLINE       0     0     0
        cache
          nvd0      ONLINE       0     0     0

L2ARC は「FreeBSD で ZFS を利用する – ZFS のキャッシュの仕組みを理解する」で解説している通りデバイスのロストによる影響はありませんので，mirror として組み込む意義はありません．キャッシュ用として二つの SSD/NVMe デバイスを持っている場合はもう一つ素直に追加して容量を増やす事の方が有意義です．

SLOG の設定

SLOG も SSD/NVMe デバイスを設定したい場合，方法は二通りあります．プールの作成時に指定するか後から追加するかです．結果に違いはありません．

上記のプールの状態の所に単体の SLOG デバイスを追加する場合は次のとおりになります．

# zpool add pool0 log nvd1

# zpool status pool0
  pool: pool0
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        pool0       ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            da1     ONLINE       0     0     0
            da2     ONLINE       0     0     0
            da3     ONLINE       0     0     0
          raidz1-1  ONLINE       0     0     0
            da4     ONLINE       0     0     0
            da5     ONLINE       0     0     0
            da6     ONLINE       0     0     0
        logs
          nvd1      ONLINE       0     0     0
        cache
          nvd0      ONLINE       0     0     0

SLOG デバイスは同期書き込み時のバッファーとして利用される事から，このデバイスがロストするとハードディスクに反映前のデータが失われる事になります．その為，L2ARC と違い SLOG はミラーで構成する事が望ましいです．

一度単体ドライブとして追加している SLOG を削除，ミラーで追加する．ということを実施してみます．

# zpool remove pool0 nvd1

# zpool status pool0
  pool: pool0
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        pool0       ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            da1     ONLINE       0     0     0
            da2     ONLINE       0     0     0
            da3     ONLINE       0     0     0
          raidz1-1  ONLINE       0     0     0
            da4     ONLINE       0     0     0
            da5     ONLINE       0     0     0
            da6     ONLINE       0     0     0
        cache
          nvd0      ONLINE       0     0     0

# zpool add pool0 log mirror nvd1 nvd2

# zpool status pool0
  pool: pool0
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        pool0       ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            da1     ONLINE       0     0     0
            da2     ONLINE       0     0     0
            da3     ONLINE       0     0     0
          raidz1-1  ONLINE       0     0     0
            da4     ONLINE       0     0     0
            da5     ONLINE       0     0     0
            da6     ONLINE       0     0     0
        logs
          mirror-5  ONLINE       0     0     0
            nvd1    ONLINE       0     0     0
            nvd2    ONLINE       0     0     0
        cache
          nvd0      ONLINE       0     0     0

logs の所が mirror として表示されており，ミラー化されている事が確認できます．

利用状況を確認する

zfs iostat で確認する

L2ARC および SLOG の利用状況を確認するには，一番手っ取り早い方法が zpool iostat コマンドでの確認になります．次のとおり -v を付ける事で各デバイスの IO 状況，L2ARC や SLOG であれば使用状況も出力する事ができます．

# zpool iostat pool0
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
pool0       14.7G   581G      0     13  17.4K  69.6K
root@bsd13-1:~ # zpool iostat -v pool0
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
pool0       14.7G   581G      0     13  17.3K  69.4K
  raidz1-0  7.34G   291G      0      6  8.51K  31.9K
    da1         -      -      0      2  2.86K  10.6K
    da2         -      -      0      2  2.86K  10.6K
    da3         -      -      0      2  2.78K  10.6K
  raidz1-1  7.35G   291G      0      6  8.16K  31.0K
    da4         -      -      0      2  2.72K  10.3K
    da5         -      -      0      2  2.74K  10.3K
    da6         -      -      0      2  2.70K  10.3K
logs            -      -      -      -      -      -
  mirror-5      0  19.5G      0      0  2.97K  28.4K
    nvd1        -      -      0      0  2.83K  14.2K
    nvd2        -      -      0      0    147  14.2K
cache           -      -      -      -      -      -
  nvd0       176K  20.0G      0      0  2.12K  1.00K
----------  -----  -----  -----  -----  -----  -----

zpool iostat は iostat 同様に引数に数字を付ける事で n秒毎の状況を確認する事が可能です．
その場合，iostat 同様に最初の出力は無視して，二つ目以降の値を見ていくのが良いです．

# zpool iostat -v pool0 5
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
pool0       14.7G   581G      0     11  14.1K  56.5K
  raidz1-0  7.34G   291G      0      5  6.94K  26.0K
    da1         -      -      0      1  2.33K  8.66K
    da2         -      -      0      1  2.33K  8.67K
    da3         -      -      0      1  2.27K  8.66K
  raidz1-1  7.35G   291G      0      5  6.65K  25.3K
    da4         -      -      0      1  2.21K  8.43K
    da5         -      -      0      1  2.23K  8.43K
    da6         -      -      0      1  2.20K  8.43K
logs            -      -      -      -      -      -
  mirror-5      0  19.5G      0      0  1.48K  14.2K
    nvd1        -      -      0      0  1.41K  7.10K
    nvd2        -      -      0      0     73  7.10K
cache           -      -      -      -      -      -
  nvd0       176K  20.0G      0      0  1.21K    587
----------  -----  -----  -----  -----  -----  -----
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
pool0       14.7G   581G      0      0      0      0
  raidz1-0  7.34G   291G      0      0      0      0
    da1         -      -      0      0      0      0
    da2         -      -      0      0      0      0
    da3         -      -      0      0      0      0
  raidz1-1  7.35G   291G      0      0      0      0
    da4         -      -      0      0      0      0
    da5         -      -      0      0      0      0
    da6         -      -      0      0      0      0
logs            -      -      -      -      -      -
  mirror-5      0  19.5G      0      0      0      0
    nvd1        -      -      0      0      0      0
    nvd2        -      -      0      0      0      0
cache           -      -      -      -      -      -
  nvd0       176K  20.0G      0      0      0      0
----------  -----  -----  -----  -----  -----  -----
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
pool0       14.7G   581G      0      0      0      0
  raidz1-0  7.34G   291G      0      0      0      0
    da1         -      -      0      0      0      0
    da2         -      -      0      0      0      0
    da3         -      -      0      0      0      0
  raidz1-1  7.35G   291G      0      0      0      0
    da4         -      -      0      0      0      0
    da5         -      -      0      0      0      0
    da6         -      -      0      0      0      0
logs            -      -      -      -      -      -
  mirror-5      0  19.5G      0      0      0      0
    nvd1        -      -      0      0      0      0
    nvd2        -      -      0      0      0      0
cache           -      -      -      -      -      -
  nvd0       176K  20.0G      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

zfs-stats パッケージを利用する

別の方法として zfs-stats パッケージを利用する方法があります．

パッケージは pkg install コマンドで簡単にインストールする事ができます．

# pkg install zfs-stats
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 2 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        perl5: 5.34.3_3
        zfs-stats: 1.3.2

Number of packages to be installed: 2

The process will require 61 MiB more space.
15 MiB to be downloaded.

Proceed with this action? [y/N]: y
[1/2] Fetching zfs-stats-1.3.2.pkg: 100%   10 KiB  10.3kB/s    00:01
[2/2] Fetching perl5-5.34.3_3.pkg: 100%   15 MiB  15.2MB/s    00:01
Checking integrity... done (0 conflicting)
[1/2] Installing perl5-5.34.3_3...
[1/2] Extracting perl5-5.34.3_3: 100%
[2/2] Installing zfs-stats-1.3.2...
[2/2] Extracting zfs-stats-1.3.2: 100%

zfs-mon

zfs-mon プログラムは，ARC の状況をリアルタイムに表示するプログラムです．

以下のとおり -a オプションで全てを表示になり，キャッシュヒット・キャッシュミスの状態も含めて表示してくれます．
停止は Ctrl+C で止める事になります．

# zfs-mon -a

ZFS real-time cache activity monitor
Seconds elapsed:   3

Cache hits and misses:
                1s    10s    60s    tot
   ARC hits:     0      1      1      1
 ARC misses:     0      0      0      0

Cache efficiency percentage:
        10s    60s    tot
ARC: 100.00 100.00 100.00

zfs-stats

zfs-stats プログラムは，起動後からの ARC などの利用状況をサマリーとして出力してくれるプログラムです．

-a オプションで全部表示できますが，500行くらいになります．-A オプションで ARC のサマリーを，-E オプションで ARC のキャッシュ利用状況を．また，-L オプションで L2ARC のステータスを表示できますので，通常はこちらの三つのオプションを利用するのが良いと思います．

-A : ARC summary

# zfs-stats -A

------------------------------------------------------------------------
ZFS Subsystem Report                            Mon Dec 25 22:21:53 2023
------------------------------------------------------------------------

ARC Summary: (HEALTHY)
        Memory Throttle Count:                  0

ARC Misc:
        Deleted:                                29
        Mutex Misses:                           0
        Evict Skips:                            3

ARC Size:                               0.44%   13.53   MiB
        Target Size: (Adaptive)         4.13%   126.89  MiB
        Min Size (Hard Limit):          4.13%   126.89  MiB
        Max Size (High Water):          24:1    3.00    GiB
        Compressed Data Size:                   685.00  KiB
        Decompressed Data Size:                 24.96   MiB
        Compression Factor:                     37.32

ARC Size Breakdown:
        Recently Used Cache Size:       50.00%  63.44   MiB
        Frequently Used Cache Size:     50.00%  63.44   MiB

ARC Hash Breakdown:
        Elements Max:                           338
        Elements Current:               100.00% 338
        Collisions:                             0
        Chain Max:                              0
        Chains:                                 0

------------------------------------------------------------------------

-E : ARC efficiency

# zfs-stats -E

------------------------------------------------------------------------
ZFS Subsystem Report                            Mon Dec 25 22:22:30 2023
------------------------------------------------------------------------

ARC Efficiency:                                 37.71   k
        Cache Hit Ratio:                99.10%  37.37   k
        Cache Miss Ratio:               0.90%   340
        Actual Hit Ratio:               98.96%  37.32   k

        Data Demand Efficiency:         100.00% 0

        CACHE HITS BY CACHE LIST:
          Anonymously Used:             0.14%   53
          Most Recently Used:           41.32%  15.44   k
          Most Frequently Used:         58.54%  21.88   k
          Most Recently Used Ghost:     0.00%   0
          Most Frequently Used Ghost:   0.00%   0

        CACHE HITS BY DATA TYPE:
          Demand Data:                  0.00%   0
          Prefetch Data:                0.00%   0
          Demand Metadata:              99.86%  37.32   k
          Prefetch Metadata:            0.14%   53

        CACHE MISSES BY DATA TYPE:
          Demand Data:                  0.00%   0
          Prefetch Data:                0.00%   0
          Demand Metadata:              78.82%  268
          Prefetch Metadata:            21.18%  72

------------------------------------------------------------------------

-L : L2 ARC statistics

# zfs-stats -L

------------------------------------------------------------------------
ZFS Subsystem Report                            Mon Dec 25 22:23:02 2023
------------------------------------------------------------------------

L2 ARC Summary: (HEALTHY)
        Low Memory Aborts:                      0
        Free on Write:                          0
        R/W Clashes:                            0
        Bad Checksums:                          0
        IO Errors:                              0

L2 ARC Size: (Adaptive)                         175.50  KiB
        Decompressed Data Size:                 9.10    MiB
        Compression Factor:                     53.10
        Header Size:                    0.00%   0       Bytes

L2 ARC Breakdown:                               241
        Hit Ratio:                      0.00%   0
        Miss Ratio:                     100.00% 241
        Feeds:                                  1.58    k

L2 ARC Writes:
        Writes Sent:                    100.00% 42

------------------------------------------------------------------------

負荷のかかってない状態で実施しているため変化がほぼ無い結果の出力で申し訳ありませんが，操作および表示については理解できるかと思います．

今回は以上としまして，次は重複排除について触れたいと思います．

FreeBSD で ZFS を利用する – ZFS のキャッシュの仕組みを理解する

seichan — Sun, 24 Dec 2023 13:00:00 +0000

今回は ZFS のキャッシュについて説明します．
ZFS は読み取り用の一次キャッシュとしてメモリーを利用します．そのほか、二次キャッシュとして高速なディスク (SSD や NVMe など) を指定する事が可能です．
そもそもの動作から説明を行っていきます．

ZFS に関するお話

ZFS のキャッシュの動作について

単純なプール構成の場合

ZFS はキャッシュの構成も様々な構成をとる事が可能です．まずは，メモリーとディスクだけの単純なプールの場合のキャッシュ動作について解説します．

一番単純な構成の場合の状態がこの絵の形となります．

初めて出る単語があるのでまずはその説明を行います．

ARC (Adaptive Replacement Cache)
最近アクセスされたファイルや頻繁にアクセスされているファイルをキャッシュし，読み取り要求時にディスクアクセスを抑制しメモリーから応答を返すためのキャッシュ領域
ZIL (ZFS Intent Log)
ディスクにデータを書き込む際のバッファー領域 (正確にはバッファーではないですが，この理解の方が分かりやすいと思います)

書き込み時

ARC は読み取りキャッシュとして動作します．書き込みキャッシュにはなりません．
書き込み時，いったん ZIL 領域に書き込みが行われ，データをトランザクショングループに纏めたのちに実際のデータとしてディスクに書き込みます．
なお，ZIL 領域はプールの一部を利用していますので，プール内のディスクから見たら2回の書き込み動作が発生するディスク群が生じます．

読み取り時

読み取りの要求が来た際，まずは ARC 内にデータがあるか確認されます．ARC 内にデータがある場合はディスクへの読み取り要求を行わずに ARC 内のデータを返して終了します．
ARC 内にデータがない場合はディスクから読み取りデータを返します．

また，そのデータは ARC にキャッシュされ，次にアクセスがあった際は ARC から返される事になります．しばらくアクセスが行われないファイルの場合は ARC からドロップされます．その場合はディスクから読み取る事が必要になります．

L2 ARC キャッシュを搭載したプールの場合

ZFS はメモリーとストレージプールの間に高速なディスク (通常は SSD や NVMe など) をキャッシュ層として追加する事が可能です．

初めて出る単語があるのでまずはその説明を行います．

L2ARC (Layer2 Adaptive Replacement Cache)
SSD や NVMe で構成する二次キャッシュ ARC から溢れたキャッシュデータが格納される

書き込み時

ARC/L2ARC 共に読み取りキャッシュとして動作します．書き込みキャッシュにはなりません．
書き込み時，いったん ZIL 領域に書き込みが行われ，データをトランザクショングループに纏めたのちに実際のデータとしてディスクに書き込みます．
なお，ZIL 領域はプールの一部を利用していますので，プール内のディスクから見たら2回の書き込み動作が発生するディスク群が生じます．
(ですので，書き込み時の動作に変更はありません)

読み取り時

読み取りの要求が来た際，まずは ARC 内にデータがあるか確認されます．ARC 内にデータがある場合はディスクへの読み取り要求を行わずに ARC 内のデータを返して終了します．
ARC 内にデータがない場合は L2ARC 内にデータがあるか確認されます．L2ARC 内にデータがある場合はディスクへの読み取り要求を行わずに L2ARC 内のデータを返して終了します．
いずれも失敗した場合はディスクから読み取りデータを返します．

また，そのデータは ARC にキャッシュされ，次にアクセスがあった際は ARC から返される事になります．しばらくアクセスが行われないファイルの場合は ARC から L2ARC に移動されます．
L2ARC 内のデータも ARC 同様にしばらくアクセスがないファイルはキャッシュから削除されます．

SLOG を搭載したプールの場合

ZFS はストレージプール内にある ZIL の手前に高速なディスク (通常は SSD や NVMe など) をバッファー層として追加する事が可能です．

初めて出る単語があるのでまずはその説明を行います．

SLOG (Secondary LOG)
ZIL の替わりになるバッファー層のディスク領域で，書き込み時のトランザクショングループを纏めるまでのバッファー層となる

書き込み時

ARC/L2ARC 共に読み取りキャッシュとして動作します．書き込みキャッシュにはなりません．
SLOG がある場合，ZIL は SLOG 内に内包 (統合) されます．
書き込み時，いったん SLOG 領域に書き込みが行われ，データをトランザクショングループに纏めたのちに実際のデータとしてディスクに書き込みます．
ZIL 領域は SLOG 内に内包され，プールの中には存在しない事になりますので，プール内のディスクから見たら1回の書き込み動作で完了する事になり，書き込み性能の向上が見込めます．

読み取り時

また，そのデータは ARC にキャッシュされ，次にアクセスがあった際は ARC から返される事になります．しばらくアクセスが行われないファイルの場合は ARC から L2ARC に移動されます．
L2ARC 内のデータも ARC 同様にしばらくアクセスがないファイルはキャッシュから削除されます．
(ここは先と変化はありません)

もっと細かい話

ZFS Caching

ZFS is an advanced file system that offers many beneficial features such as pooled storage, data scrubbing, capacity and...

の和訳です．

ZFS は，プール化されたストレージ，データスクラビング，圧縮や重複排除など，多くの有益な機能を提供する高度なファイルシステムです．
ですが，ZFS の最も有益な機能の一つは，読み取りと書き込みをキャッシュする方法です．
ZFS はメモリーを使用してデータを階層的にキャッシュします．

ZFS のキャッシュの一番目のレベルは ARC です．ARC 内のすべての領域が使用されると ZFS は最新の頻繁に使用されたデータを L2ARC に配置します．

ARC と L2ARC，ZIL および SLOG はそれぞれが実際にどのような役割を果たすのかについて各方面で説明にブレがあり混乱を生じさせています．

ARC，L2ARC は読み取りキャッシュです．これらは，システムがデータを見つける必要があるたびに低速なディスクへのアクセスを行う必要がないようにサーバーでの読み取りを高速化するために存在します．

書き込みの場合，ZIL はあくまでもログであり、別のログデバイス (SLOG) が存在する場合でも，実際には書き込みキャッシュではありません．(書き込みキャッシュと呼ばれることが多いですが) ．

ここでは，それらすべての用語が何を行うのか、また，それらを実装することでサーバーにどのようなメリットがあるのかを明らかにします．
まず書き込み．つまり ZIL と SLOG について説明します．

書き込み

ZFS は書き込み要求を受けると，即ディスクへの書き込みを開始するのではなく，書き込みを RAM にキャッシュしてから，設定された間隔 (デフォルトは 5 秒) でトランザクショングループ (TXG) に送信します．
これはトランザクションファイルシステムと呼ばれます．

これによって、ディスクへの書き込みがより適切に整理され，ディスクの処理が大きく簡素化されるため，パフォーマンスが向上します．
また，電源障害が発生した場合でも部分的な書き込みが発生しないため，データの一貫性にもメリットがあります．
電源障害が発生した場合，TXG 内のすべてのデータが破棄される事になります．

ZFS が書き込みを処理する方法の基本を理解するには，同期書き込みと非同期書き込みの違いを理解する必要があります．

非同期書き込み

データはすぐにメモリーにキャッシュされ，クライアントには書き込み完了が返され，その後ディスクに書き込まれます．

クライアントが書き込みリクエストを送信すると，そのリクエストは直ちにメモリーに保存されます．
その後，サーバーは書き込みが完了したことをクライアントに通知します．
トランザクショングループが RAM に保存されると，サーバーはトランザクショングループをまとめてディスクに書き込むまで，ディスクに何も書き込まずにさらにリクエストを受け付けます．
非同期書き込みは，データが高速なメモリーに保存されるだけで完了したとみなされるため，ユーザーから見た場合は非常に高速な書き込みプロセスです．

問題は，データの一貫性は維持されますが，電源障害が発生するとトランザクショングループはメモリーにのみ存在するためすべてが失われます．
同期書き込みはデータの一貫性を確保することを目的としていますが，パフォーマンスが犠牲になります．

同期書き込み SLOG が無い場合

書き込みが完了したとみなされる前に，ディスクに書き込まれたことが確認される必要があります．

クライアントが同期書き込みの書き込みリクエストを送信すると，非同期書き込みと同様に最初にメモリーに保存されますが，サーバーは ZIL に記録されるまで書き込みが完了したことを通知しません．

ZIL が更新されると，書き込みがコミットされ，書き込み完了の通知が行われます．ZIL はデフォルトでストレージプールの一部として存在します．つまり，ZIL を更新し，実際にデータをプールのに保存するには，ハードディスクのヘッドの場所を物理的に移動する必要があるため，パフォーマンスにさらに影響します．特に小さなランダム書き込みの場合に，パフォーマンスの問題が発生します．

同期書き込みによる速度の低下や望ましくないデータ損失に対する ZFS の解決策は，ZIL を通常は SSD や NVMe などの別の高速永続ストレージデバイスに配置することです．

SLOG を使用した同期書き込み

ZIL が SSD/NVMe に格納されている場合，クライアントの同期書き込みリクエストは ZIL に高速に記録されます．こうすることで，停電により RAM 上のデータが失われた場合でも，システムは次に電源が入ったときに ZIL をチェックし，コミット前のデータを見つけることが可能になります．

あるいは，データは ZIL に保存されたデータへのポインタとともに，すぐにディスクに書き込まれることもあります．
次の TXG が送信された後，正しい場所を指すようにデータのメタデータが更新されます．
停電が発生した場合，サーバーは ZIL をチェックしてデータがどこにあるかを見つけます．システムは実際には，次のトランザクショングループが通過するまでデータがどこに格納されているかを認識しておらず，メタデータにはデータの格納場所が表示されないため ZIL を確認する必要がありました．
SLOG に関して注意すべき点の 1 つは，電源障害が発生した場合にデータの一貫性を確保するというジョブを実行できるようにミラーリングすることが最善であるということです．

SLOG はパフォーマンスにどの程度貢献するのか

SLOG のインパクト，パフォーマンスはアプリケーションによって異なります．
小規模な IO では大幅な改善が見られ，シーケンシャル IO でもかなりの改善が見られる可能性があります．
データベースサーバーやホスティング VM などのユースケースなど，多くの同期書き込みの場合にも役立つ可能性があります．ただし、SLOG の主な機能はパフォーマンスの向上ではなく，停電時に失われるデータを保存することです．
ミッションクリティカルなアプリケーションの場合，次のトランザクショングループが送信される 5 秒間のデータが失われると，かなりの影響が発生する可能性があります．これが，SLOG が実際にはキャッシュではなく，その名前が示すようにログである理由でもあります．SLOG には，予期しない電源障害が発生した場合にのみアクセスされます．

失われる可能性のある 5 秒間のデータが重要な場合は，パフォーマンスの低下と引き換えにすべての書き込みを強制的に同期として実行することができます．
そのデータにミッションクリティカルなものがない場合は，同期を無効にすることができ，トランザクショングループが失われる危険性はあるものの，すべての書き込みは単純にメモリーをキャッシュとして使用できます．標準同期はデフォルトであり，書き込みごとにアプリケーションと ZFS によって決定されます．

SLOG 用のデバイスを選択するための非公式の要件は，単一のキュー深さで適切に機能するドライブを選択することです．同期書き込みは，ほとんどの SSD が最も得意とする大規模なバッチでは行われないため，標準の SSD を使用すると実際にはパフォーマンスが低下する可能性があります．Intel Optane ドライブは，低いキュー深度での高速性と，停電時に書き込みを完了するバッテリーのおかげで，一般に SLOG として使用するのに最適なドライブの 1 つと考えられています．データを保存するという目的を達成するには、SLOG にバッテリーを搭載することが重要です．

※ Intel Optane は廃止になってしまっているので，SSD や NVMe をバッテリーバックアップ可能な構成にして利用する．が現状の解となると思います．

読み取り

書き込みと同様に，ZFS は読み取りをメモリーにキャッシュします．読み取りキャッシュを ARC と呼んでいます．これは IBM ARC の修正バージョンであり，ARC が使用するより複雑なアルゴリズムにより，平均的な読み取りキャッシュよりも高性能です．

ARC

ARC は，最近使用されたデータと最も頻繁に使用されたデータをメモリーに保存することによって機能します．メモリー上の ARC に存在するデータはディスク上のストレージプールにも存在するため，これは ZIL とは異なり，本当のキャッシュ機能です．
読み取りパフォーマンスの高速化に役立つのは ARC のみであり，通常は優れたパフォーマンスを発揮します．大規模な ARC を使用すると，大量のメモリーが占有される可能性がありますが，他のアプリケーションが必要とする場合はそのメモリを放棄し，システムに最適と思われる値に設定できます．

ARC は，コールドヒットが発生するたびに，どちらかにより多くのスペースを割り当てることにより，最近使用されたデータと最も頻繁に使用されたデータの割合を変更して使用します．
コールドヒットは，以前にキャッシュされていたものの，ARC が新しいデータを格納できるようにするためにすでにプッシュされていたデータの一部が要求された場合に発生します．
ZFS は，コールドヒットを認識できるようにするために，キャッシュが削除された後にどのデータがキャッシュに保存されたかを追跡します．新しいデータが入ってくると，しばらく使用されていないデータや，新しいデータほど使用されていないデータが押し出されます．

システムのメモリーが多いほど，読み取りパフォーマンスが向上するため，より優れています．マザーボードのメモリースロットと予算の制約により，ARC を追加するには物理的およびコストの制限があります．ヒット率が高くならず ARC がいっぱいになっており，システムにこれ以上のメモリーを搭載できない場合は，L2ARC の追加を検討することをお勧めします．

L2ARC

L2ARC は，高速なメモリーではなく SSD や NVMe 上に構成します．ただし、ハードディスクよりもはるかに高速であるため，ARC のヒット率が低い場合は，L2ARC を追加する事でパフォーマンスが向上する可能性があります．
ハードディスクからデータを見つける代わりに，システムはメモリーと SSD/NVMe を調べてパフォーマンスを向上させます．通常，64 GB 以上のメモリーを搭載しているにもかかわらず，ARC のヒット率が 90% 未満の場合 L2ARC が検討されます．

L2ARC がいっぱいになるのは，ARC がいっぱいになり，そのアルゴリズムがより重要であると判断した新しいデータ用のスペースを空ける場合に限られます．この排出されたデータは L2ARC に移動されます．L2ARC がいっぱいになるまでに長い時間がかかる可能性があります．

※ L2ARC は，L2ARC に保存されるすべてのデータはストレージプール内に存在するため，SLOG のようにミラーリングする必要はありません．

L2ARC は，そこに保存されているデータを追跡するためにメモリー上の一定量のスペースを使用するため，通常は L2ARC を検討する前にメモリーを追加することをお勧めします．
SSD/NVMe はハードディスクより高価ですが，メモリーよりははるかに安いため，この決定を行う際には，価格とパフォーマンスのトレードオフを発生させる可能性があります．

まとめ

ZIL は，確認がクライアントに送り返される前に同期書き込みが記録されるスペースです．デフォルトでは，ストレージプールの一部として存在します．
SLOG は，ZIL が存在する別のデバイスです．一部の特定の用途ではパフォーマンスが向上する可能性があります．ただし、その主な機能は、停電時に失われる可能性があるデータを保存することです．
ARC は，読み取りパフォーマンスを高速化するためにデータをキャッシュするために使用される RAM の一部です．
L2ARC は ARC の拡張機能であり，通常は SSD/NVMe 上にあります．これは，メモリーを追加するという物理的な制約を回避しながら，ARC のサイズを増やすことを目的としています．

和訳も追加をさせて頂きましたが，ZFS のキャッシュの仕組みの説明でした．
ARC/L2ARC や ZIL/SLOG について理解が深められればと思います．

次回ですが，実際に ARC の設定や L2ARC，SLOG デバイスの追加などオペレーションの方法を解説したいと考えています．

FreeBSD で ZFS を利用する – ファイルシステムの圧縮を利用する・比較する

seichan — Sat, 23 Dec 2023 13:00:00 +0000

今回は ZFS の大きな特徴の一つである，圧縮にフォーカスしたいと思います．
ZFS はファイルシステム (ZVOLも) の圧縮が利用でき，透過的に圧縮・展開が行われます．
これによってストレージ利用量の削減が見込めます．

ZFS に関するお話

ファイルシステムの圧縮
それぞれのアルゴリズムでの圧縮・展開の測定
まとめ
1. 書き込み時 (圧縮時)
2. 読み出し時 (展開時)

ファイルシステムの圧縮

ZFS でのファイルシステムの圧縮にはいくつかのアルゴリズムがあります．
それぞれ得手・不得手がありますので格納するデータに応じた圧縮方式を適用することが推奨されます．

LZ4
圧縮・展開の速さ，CPU 負荷の少なさに定評があり，現在 compression=on の場合のデフォルト値となっている．ZSTD よりも高速と言われている．
GZIP
圧縮率は高いが CPU 負荷も高い．バックアップ領域など静的なデータを長期保存し普段読み書きアクセスを頻繁に行わない所には良いと思う．
LZJB
LZ4 と GZIP の中間位の立ち位置で，圧縮率に優れている．展開は LZ4 の方が速い．
ZLE
連続するゼロデータ (0 が連続するデータ) の所のみ圧縮を行う．負荷は低いが効果も低い．
ZSTD
たぶん今後のスタンダードになるもの．圧縮・展開の速さは LZ4 と同等，圧縮率が GZIP に近しい．CPU 負荷は LZ4 より少し高い．というもの

と，色々ありますので，それぞれどのような効果・パフォーマンスなのかを測定してみます．

それぞれのアルゴリズムでの圧縮・展開の測定

測定の方法ですが，各ファイルシステムにFreeBSD のソースファイル「src_stable_13.tar.xz」を展開して展開にかかる時間，圧縮率の測定．
また，逆に展開されたソースファイル群を tar で読み出して /dev/null に書き出してかかる時間を測定してみます．

時間に関しては仮想環境上ですのでブレが生じる事を前提に見て頂ければと思います．
CPU 負荷についてはこれも仮想上なのでより参考にできないと思いますので取得しません．

LZ4

まず，LZ4 で圧縮するファイルシステムの作成を行います．

# zfs create pool0/lz4

# zfs set compression=lz4 pool0/lz4
# zfs get compression pool0/lz4
NAME       PROPERTY     VALUE           SOURCE
pool0/lz4  compression  lz4             local

# mkdir /pool0/lz4/src1
# mkdir /pool0/lz4/src2
# mkdir /pool0/lz4/src3

3回実施して計測しますので，/pool0/lz4/src[1-3] ができると理解ください．

書き込み: 1回目

# cd /pool0/lz4/src1

# date ; tar -Jxf /root/src_stable_13.tar.xz ; date
Sat Dec 23 13:25:38 JST 2023
Sat Dec 23 13:26:01 JST 2023

# zfs get compressratio pool0/lz4
NAME       PROPERTY       VALUE  SOURCE
pool0/lz4  compressratio  2.42x  -

書き込み: 2回目

# cd /pool0/lz4/src2

# date ; tar -Jxf /root/src_stable_13.tar.xz ; date
Sat Dec 23 13:27:29 JST 2023
Sat Dec 23 13:27:50 JST 2023

# zfs get compressratio pool0/lz4
NAME       PROPERTY       VALUE  SOURCE
pool0/lz4  compressratio  2.42x  -

書き込み: 3回目

# cd /pool0/lz4/src3

# date ; tar -Jxf /root/src_stable_13.tar.xz ; date
Sat Dec 23 13:28:55 JST 2023
Sat Dec 23 13:29:17 JST 2023

# zfs get compressratio pool0/lz4
NAME       PROPERTY       VALUE  SOURCE
pool0/lz4  compressratio  2.42x  -

書き込み: まとめ

1回目 23秒，2回目 21秒，3回目 22秒．平均22秒かかりました．
圧縮率は 2.42 ということで元データと比較して 140% の圧縮率でした．
なお，1.00 が無圧縮となります

ちなみに，展開したデータの実容量としては次のとおり 613MB です．

# du -sk /pool0/lz4/src1
628350  /pool0/lz4/src1

読み出し: 1回目

# cd /pool0/lz4/src1

# date ; tar -cf /dev/null ./ ; date
Sat Dec 23 13:34:21 JST 2023
Sat Dec 23 13:34:26 JST 2023

読み出し: 2回目

# date ; tar -cf /dev/null ./ ; date
Sat Dec 23 13:35:09 JST 2023
Sat Dec 23 13:35:13 JST 2023

読み出し: 3回目

# date ; tar -cf /dev/null ./ ; date
Sat Dec 23 13:35:58 JST 2023
Sat Dec 23 13:36:01 JST 2023

読み出し: まとめ

1回目が5秒，2回目が4秒，3回目が3秒でした．ですので平均4秒で 630MB の読み出しができている事になります．
なお，2回目以降はキャッシュに入ったので速度が上がる可能性が高いです．

GZIP

まず，GZIP で圧縮するファイルシステムの作成を行います．

# zfs create pool0/gzip

# zfs set compression=gzip pool0/gzip

# zfs get compression pool0/gzip
NAME        PROPERTY     VALUE           SOURCE
pool0/gzip  compression  gzip            local

# mkdir /pool0/gzip/src1
# mkdir /pool0/gzip/src2
# mkdir /pool0/gzip/src3

3回実施して計測しますので，/pool0/gzip/src[1-3] ができると理解ください．

書き込み: 1回目

# cd /pool0/gzip/src1

# date ; tar -Jxf /root/src_stable_13.tar.xz ; date
Sat Dec 23 13:41:44 JST 2023
Sat Dec 23 13:42:23 JST 2023

# zfs get compressratio pool0/gzip
NAME        PROPERTY       VALUE  SOURCE
pool0/gzip  compressratio  3.60x  -

書き込み: 2回目

# cd /pool0/gzip/src2

# date ; tar -Jxf /root/src_stable_13.tar.xz ; date
Sat Dec 23 13:43:17 JST 2023
Sat Dec 23 13:43:57 JST 2023

# zfs get compressratio pool0/gzip
NAME        PROPERTY       VALUE  SOURCE
pool0/gzip  compressratio  3.59x  -

書き込み: 3回目

# cd /pool0/gzip/src3
# date ; tar -Jxf /root/src_stable_13.tar.xz ; date
Sat Dec 23 13:44:46 JST 2023
Sat Dec 23 13:45:25 JST 2023

# zfs get compressratio pool0/gzip
NAME        PROPERTY       VALUE  SOURCE
pool0/gzip  compressratio  3.59x  -

書き込み: まとめ

1回目 39秒，2回目 40秒，3回目 39秒．平均39秒かかりました．
圧縮率は 3.59 ということで元データと比較して 260% の圧縮率でした．
LZ4 と比べて時間 (CPU 負荷) は高いものの，圧縮率はとても良いことが分かります．

読み出し: 1回目

# cd /pool0/gzip/src1

# date ; tar -cf /dev/null ./ ; date
Sat Dec 23 13:49:34 JST 2023
Sat Dec 23 13:49:56 JST 2023

読み出し: 2回目

# date ; tar -cf /dev/null ./ ; date
Sat Dec 23 13:50:01 JST 2023
Sat Dec 23 13:50:09 JST 2023

読み出し: 3回目

# date ; tar -cf /dev/null ./ ; date
Sat Dec 23 13:50:49 JST 2023
Sat Dec 23 13:50:57 JST 2023

読み出し: まとめ

1回目が22秒，2回目が8秒，3回目が8秒でした．ですので平均13秒で 630MB の読み出しができている事になります．
なお，2回目以降はキャッシュに入ったので速度が上がる可能性が高いです．
LZ4 と1回目の比較をすると17秒の違いがありますので，圧縮データの展開時も CPU 負荷は高めだと思います．

LZJB

まず，LZJB で圧縮するファイルシステムの作成を行います．

# zfs create pool0/lzjb

# zfs set compression=lzjb pool0/lzjb

# zfs get compression pool0/lzjb
NAME        PROPERTY     VALUE           SOURCE
pool0/lzjb  compression  lzjb            local


# mkdir /pool0/lzjb/src1
# mkdir /pool0/lzjb/src2
# mkdir /pool0/lzjb/src3

3回実施して計測しますので，/pool0/lzjb/src[1-3] ができると理解ください．

書き込み: 1回目

# cd /pool0/gzip/src1

# date ; tar -Jxf /root/src_stable_13.tar.xz ; date
Sat Dec 23 13:58:24 JST 2023
Sat Dec 23 13:58:51 JST 2023

# zfs get compressratio pool0/lzjb
NAME        PROPERTY       VALUE  SOURCE
pool0/lzjb  compressratio  2.12x  -

書き込み: 2回目

# cd /pool0/lzjb/src2

# date ; tar -Jxf /root/src_stable_13.tar.xz ; date
Sat Dec 23 13:59:36 JST 2023
Sat Dec 23 13:59:58 JST 2023

# zfs get compressratio pool0/lzjb
NAME        PROPERTY       VALUE  SOURCE
pool0/lzjb  compressratio  2.12x  -

書き込み: 3回目

# cd /pool0/lzjb/src3

# date ; tar -Jxf /root/src_stable_13.tar.xz ; date
Sat Dec 23 14:00:43 JST 2023
Sat Dec 23 14:01:05 JST 2023

# zfs get compressratio pool0/lzjb
NAME        PROPERTY       VALUE  SOURCE
pool0/lzjb  compressratio  2.12x  -

書き込み: まとめ

1回目 27秒，2回目 22秒，3回目 22秒．平均24秒かかりました．
圧縮率は 2.12 ということで元データと比較して 210% の圧縮率でした．
LZ4 と比べて時間 (CPU 負荷) は高いものの，GZIP 程ではなく，圧縮率も GZIP 程ではないものの良い結果となっています．

読み出し: 1回目

# cd /pool0/lzjb/src1

# date ; tar -cf /dev/null ./ ; date
Sat Dec 23 14:05:17 JST 2023
Sat Dec 23 14:05:59 JST 2023

読み出し: 2回目

# date ; tar -cf /dev/null ./ ; date
Sat Dec 23 14:06:34 JST 2023
Sat Dec 23 14:06:40 JST 2023

読み出し: 3回目

# date ; tar -cf /dev/null ./ ; date
Sat Dec 23 14:07:05 JST 2023
Sat Dec 23 14:07:12 JST 2023

読み出し: まとめ

1回目が42秒，2回目が6秒，3回目が7秒でした．初回が GZIP より時間がかかっているのは予定外です．本来は少なくなるはず… 平均18秒で 630MB の読み出しができている事になります．
2回目，3回目の値が GZIP に比べて低いため，やり直せば1回目も値が違ってきているとは思います．
いずれにぜよ，速度・圧縮率の観点で LZ4 と GZIP の間に位置する事はわかるかと思います．

ZLE

まず，ZLE で圧縮するファイルシステムの作成を行います．

# zfs create pool0/zle

# zfs set compression=zle pool0/zle

# zfs get compression pool0/zle
NAME       PROPERTY     VALUE           SOURCE
pool0/zle  compression  zle             local

# mkdir /pool0/zle/src1
# mkdir /pool0/zle/src2
# mkdir /pool0/zle/src3

3回実施して計測しますので，/pool0/zle/src[1-3] ができると理解ください．

書き込み: 1回目

# cd /pool0/zle/src1

# date ; tar -Jxf /root/src_stable_13.tar.xz ; date
Sat Dec 23 14:22:48 JST 2023
Sat Dec 23 14:23:13 JST 2023

# zfs get compressratio pool0/zle
NAME       PROPERTY       VALUE  SOURCE
pool0/zle  compressratio  1.07x  -

書き込み: 2回目

# cd /pool0/zle/src2

# date ; tar -Jxf /root/src_stable_13.tar.xz ; date
Sat Dec 23 14:24:41 JST 2023
Sat Dec 23 14:25:06 JST 2023

# zfs get compressratio pool0/zle
NAME       PROPERTY       VALUE  SOURCE
pool0/zle  compressratio  1.07x  -

書き込み: 3回目

# cd /pool0/zle/src3

# date ; tar -Jxf /root/src_stable_13.tar.xz ; date
Sat Dec 23 14:25:46 JST 2023
Sat Dec 23 14:26:10 JST 2023

# zfs get compressratio pool0/zle
NAME       PROPERTY       VALUE  SOURCE
pool0/zle  compressratio  1.07x  -

書き込み: まとめ

1回目 25秒，2回目 25秒，3回目 24秒．平均25秒かかりました．
圧縮率は 1.07 ということで元データと比較して 10% 未満の圧縮率でした．
初めて試してみましたが，これは自分が採用する事はないな．と思いました．
通常のファイルサーバーとしての利用の場合，これを採用するメリットはないと思います．データベース製品で最初にファイルシステムにゼロ埋めを行うものがありますが，こういったものには有効なのだと思いますが…

読み出し: 1回目

# cd /pool0/zle/src1

# date ; tar -cf /dev/null ./ ; date
Sat Dec 23 14:30:22 JST 2023
Sat Dec 23 14:31:08 JST 2023

読み出し: 2回目

# date ; tar -cf /dev/null ./ ; date
Sat Dec 23 14:31:35 JST 2023
Sat Dec 23 14:32:05 JST 2023

読み出し: 3回目

# date ; tar -cf /dev/null ./ ; date
Sat Dec 23 14:32:30 JST 2023
Sat Dec 23 14:32:53 JST 2023

読み出し: まとめ

1回目が46秒，2回目が30秒，3回目が23秒でした．圧縮されているデータがそもそも少ないため，読み出しにかかる量が多くなりその結果時間がかかっているという状況だと思います．

ZSTD

まず，ZSTD で圧縮するファイルシステムの作成を行います．

# zfs create pool0/zstd
root@bsd13-1:/pool0/zle/src1 # zfs set compression=zstd pool0/zstd
root@bsd13-1:/pool0/zle/src1 # zfs get compression pool0/zstd
NAME        PROPERTY     VALUE           SOURCE
pool0/zstd  compression  zstd            local

# mkdir /pool0/zstd/src1
# mkdir /pool0/zstd/src2
# mkdir /pool0/zstd/src3

3回実施して計測しますので，/pool0/zstd/src[1-3] ができると理解ください．

書き込み: 1回目

# cd /pool0/zstd/src1

# date ; tar -Jxf /root/src_stable_13.tar.xz ; date
Sat Dec 23 14:38:29 JST 2023
Sat Dec 23 14:38:52 JST 2023

# zfs get compressratio pool0/zstd
NAME        PROPERTY       VALUE  SOURCE
pool0/zstd  compressratio  3.47x  -

書き込み: 2回目

# cd /pool0/zstd/src2

# date ; tar -Jxf /root/src_stable_13.tar.xz ; date
Sat Dec 23 14:39:45 JST 2023
Sat Dec 23 14:40:07 JST 2023

# zfs get compressratio pool0/zstd
NAME        PROPERTY       VALUE  SOURCE
pool0/zstd  compressratio  3.47x  -

書き込み: 3回目

# cd /pool0/zstd/src3

# date ; tar -Jxf /root/src_stable_13.tar.xz ; date
Sat Dec 23 14:40:58 JST 2023
Sat Dec 23 14:41:21 JST 2023

# zfs get compressratio pool0/zstd
NAME        PROPERTY       VALUE  SOURCE
pool0/zstd  compressratio  3.47x  -

書き込み: まとめ

1回目 23秒，2回目 22秒，3回目 23秒．平均23秒かかりました．
圧縮率は 3.47 ということで元データと比較して 240% の圧縮率でした．
GZIP よりは多少劣りますがかかる時間は LZ4 並みの時間でした．

読み出し: 1回目

# cd /pool0/zstd/src1

# date ; tar -cf /dev/null ./ ; date
Sat Dec 23 14:45:21 JST 2023
Sat Dec 23 14:45:36 JST 2023

読み出し: 2回目

# date ; tar -cf /dev/null ./ ; date
Sat Dec 23 14:46:13 JST 2023
Sat Dec 23 14:46:26 JST 2023

読み出し: 3回目

# date ; tar -cf /dev/null ./ ; date
Sat Dec 23 14:46:47 JST 2023
Sat Dec 23 14:47:15 JST 2023

読み出し: まとめ

1回目が15秒，2回目が13秒，3回目が28秒でした．3回目が遅いのは環境の問題が高いと思います．
平均としては19秒で，GZIP よりは速く，LZ4 や LZJB より遅いという結果です．

まとめ

これらを纏めると次のとおりとなります．

書き込み時 (圧縮時)

アルゴリズム	1回目	2回目	3回目	平均	圧縮率
LZ4	23秒	21秒	22秒	22秒	2.42
GZIP	39秒	40秒	39秒	39秒	3.59
LZJB	27秒	22秒	22秒	24秒	2.12
ZLE	25秒	25秒	25秒	24秒	1.07
ZSTD	23秒	22秒	23秒	23秒	3.47

書き込み時の速度で並べると LZ4 -> ZSTD -> LZJB | ZLE -> GZIP の順番
圧縮率で並べると GZIP -> ZSTD -> LZ4 -> LZJB -> ZLE の順番でした．

読み出し時 (展開時)

アルゴリズム	1回目	2回目	3回目	平均
LZ4	5秒	4秒	3秒	4秒
GZIP	22秒	8秒	8秒	13秒
LZJB	42秒	6秒	7秒	18秒
ZLE	46秒	30秒	23秒	33秒
ZSTD	15秒	13秒	28秒	19秒

読み出し時の速度で見ると LZ4 -> GZIP -> ZSTD -> LZJB -> ZLE の順番でした．

仮想環境上での比較ですのでちょっとしたことでブレが発生しますが，それぞれの圧縮アルゴリズムの特徴が理解できたのではないでしょうか．

ファイルサーバーとして読み書き速度を最重要視したい場合は LZ4 になると思います．圧縮率も重視したい場合は ZSTD を選択．という形に．また，アーカイブやバックアップ目的は GZIP を採用というのが特性に合っているかと思います．

実際の所は自身のファイルサーバーの目的・役割に応じて選択いただくことになりますが，概ねの傾向として参考にして頂ければと思います．

FreeBSD で ZFS を利用する – RAWボリュームを切り出す & iSCSI として提供する

seichan — Fri, 22 Dec 2023 13:00:00 +0000

今回は ZFS ファイルシステムではなく，ボリュームとして切り出して利用したり，ボリュームを iSCSI として提供したりしてみます．

ZFS に関するお話

ブロックデバイスとして切り出す
1. 自ホスト内で UFS フォーマットしてみる
2. ボリュームを拡張してみる
iSCSI で提供する
1. ターゲットを設定する

ブロックデバイスとして切り出す

ZFS のストレージプールからブロックデバイスとして切り出すことが可能です．

ZFS の中にボリュームを切り出して UFS フォーマットで利用する (またはその他のファイルシステムフォーマットを行う) ことや，iSCSI や GEOM GATE で他ホストへ共有を行うことができます．

ボリュームの作成も zfs create で行います．

# zfs create -V 10G pool0/zvol0

# zfs list
NAME                USED  AVAIL     REFER  MOUNTPOINT
pool0              10.3G  86.1G       24K  /pool0
pool0/data-backup  26.5K  86.1G     26.5K  /pool0/data-backup
pool0/zvol0        10.3G  96.4G       12K  -

この場合，zvol0 を 10GB で切り出しています．MOUNTPOINT が何もなく，マウントされていないことが分かります．
それ以外は ZFS の機能は利用可能です．スナップショットやクローン，圧縮・重複排除などをボリュームに対して適用できます．
ですので，このように zfs の設定は通常の ZFS ファイルシステムと大きく違いはありません．

# zfs get all pool0/zvol0
NAME         PROPERTY              VALUE                  SOURCE
pool0/zvol0  type                  volume                 -
pool0/zvol0  creation              Thu Dec 21 20:38 2023  -
pool0/zvol0  used                  10.3G                  -
pool0/zvol0  available             96.4G                  -
pool0/zvol0  referenced            12K                    -
pool0/zvol0  compressratio         1.00x                  -
pool0/zvol0  reservation           none                   default
pool0/zvol0  volsize               10G                    local
pool0/zvol0  volblocksize          8K                     default
pool0/zvol0  checksum              on                     default
pool0/zvol0  compression           off                    default
pool0/zvol0  readonly              off                    default
pool0/zvol0  createtxg             24146                  -
pool0/zvol0  copies                1                      default
pool0/zvol0  refreservation        10.3G                  local
pool0/zvol0  guid                  6841428395991112135    -
pool0/zvol0  primarycache          all                    default
pool0/zvol0  secondarycache        all                    default
pool0/zvol0  usedbysnapshots       0B                     -
pool0/zvol0  usedbydataset         12K                    -
pool0/zvol0  usedbychildren        0B                     -
pool0/zvol0  usedbyrefreservation  10.3G                  -
pool0/zvol0  logbias               latency                default
pool0/zvol0  objsetid              334                    -
pool0/zvol0  dedup                 off                    default
pool0/zvol0  mlslabel              none                   default
pool0/zvol0  sync                  standard               default
pool0/zvol0  refcompressratio      1.00x                  -
pool0/zvol0  written               12K                    -
pool0/zvol0  logicalused           6K                     -
pool0/zvol0  logicalreferenced     6K                     -
pool0/zvol0  volmode               default                default
pool0/zvol0  snapshot_limit        none                   default
pool0/zvol0  snapshot_count        none                   default
pool0/zvol0  snapdev               hidden                 default
pool0/zvol0  context               none                   default
pool0/zvol0  fscontext             none                   default
pool0/zvol0  defcontext            none                   default
pool0/zvol0  rootcontext           none                   default
pool0/zvol0  redundant_metadata    all                    default
pool0/zvol0  encryption            off                    default
pool0/zvol0  keylocation           none                   default
pool0/zvol0  keyformat             none                   default
pool0/zvol0  pbkdf2iters           0                      default

自ホスト内で UFS フォーマットしてみる

作成されたボリュームにアクセスするには /dev/zvol/[プール名]/[ボリューム名] でアクセスが可能です．
ファイルシステムを作成してマウントをしてみます．

# newfs /dev/zvol/pool0/zvol0
/dev/zvol/pool0/zvol0: 10240.0MB (20971520 sectors) block size 32768, fragment size 4096
        using 17 cylinder groups of 625.22MB, 20007 blks, 80128 inodes.
super-block backups (for fsck_ffs -b #) at:
 192, 1280640, 2561088, 3841536, 5121984, 6402432, 7682880, 8963328, 10243776, 11524224, 12804672, 14085120, 15365568,
 16646016, 17926464, 19206912, 20487360

# mount /dev/zvol/pool0/zvol0 /mnt

# df
Filesystem            1K-blocks    Used    Avail Capacity  Mounted on
/dev/da0p2             19279260 2223580 15513340    13%    /
devfs                         1       1        0   100%    /dev
/dev/da2              101561756   10600 93426216     0%    /mnt
pool0                  90273061      24 90273037     0%    /pool0
pool0/data-backup      90273064      26 90273037     0%    /pool0/data-backup
/dev/zvol/pool0/zvol0  10144028       8  9332500     0%    /mnt

通常このような使い方を行うことはないと思いますが，こういったこともできますという例になります．

ボリュームを拡張してみる

ZFS で作成したボリュームは簡単に拡張・縮小が可能です．縮小は上位のファイルシステムも対応している必要があります．
今回はボリュームを拡張し，ファイルシステムも拡張してみる．ということを実施します．

# zfs set volsize=20G pool0/zvol0

# zfs list
NAME                USED  AVAIL     REFER  MOUNTPOINT
pool0              20.6G  75.8G       24K  /pool0
pool0/data-backup  26.5K  75.8G     26.5K  /pool0/data-backup
pool0/zvol0        20.6G  96.4G     1.84M  -

# df
Filesystem            1K-blocks    Used    Avail Capacity  Mounted on
/dev/da0p2             19279260 2223580 15513340    13%    /
devfs                         1       1        0   100%    /dev
/dev/da2              101561756   10600 93426216     0%    /mnt
pool0                  79458977      24 79458953     0%    /pool0
pool0/data-backup      79458979      26 79458953     0%    /pool0/data-backup
/dev/zvol/pool0/zvol0  10144028       8  9332500     0%    /mnt

# growfs /dev/zvol/pool0/zvol0
Device is mounted read-write; resizing will result in temporary write suspension for /mnt.
It's strongly recommended to make a backup before growing the file system.
OK to grow filesystem on /dev/zvol/pool0/zvol0, mounted on /mnt, from 10GB to 20GB? [yes/no] yes
super-block backups (for fsck_ffs -b #) at:
 21767808, 23048256, 24328704, 25609152, 26889600, 28170048, 29450496, 30730944, 32011392, 33291840, 34572288, 35852736,
 37133184, 38413632, 39694080, 40974528

# df
Filesystem            1K-blocks    Used    Avail Capacity  Mounted on
/dev/da0p2             19279260 2223580 15513340    13%    /
devfs                         1       1        0   100%    /dev
/dev/da2              101561756   10600 93426216     0%    /mnt
pool0                  79458969      24 79458945     0%    /pool0
pool0/data-backup      79458972      26 79458945     0%    /pool0/data-backup
/dev/zvol/pool0/zvol0  20308252       8 18683584     0%    /mnt

このように簡単に拡張することができます．

iSCSI で提供する

まず，FreeBSD の iSCSI については以下で記事にしていますのでこちらも合わせてご覧ください．

その上で，サーバー (ターゲット) から提供する．という所に絞って説明を行います．
もちろん，ZFS ボリュームを切り出すのではなく，ZFS ファイルシステム内のボリュームファイルを提供することも可能です．

ターゲットを設定する

先ほど作成したボリューム vol0 を iSCSI ターゲットに載せてみます．以下設定ファイルは前回のものを流用しています．詳細は上部にリンクを張った記事をご覧ください．
違いは lun0 で指定しているデバイスファイルのパス，lun 1 で指定しているパスだけになります．

# cat /etc/ctl.conf
auth-group ag0 {
  chap-mutual "iscsi-user1" "Password-user1" "mutual-user" "Password-mutual"
  initiator-portal 172.16.255.0/24
  initiator-portal 172.17.255.0/24
}

portal-group pg0 {
  discovery-auth-group no-authentication
  listen 172.16.255.254:3260
  listen 172.17.255.254:3260
}

target iqn.2023-12.iscsi.org.seichan:target0 {
  alias "target0"
  auth-group ag0
  portal-group pg0
  lun 0 {
    path /dev/zvol/pool0/zvol0
    option vendor "FreeBSD"
  }
  lun 1 {
    path /pool0/lun1.img
    option vendor "FreeBSD"
    blocksize 4096
    size 10G
  }
}

この設定ファイルを用いて ctld を起動します．

# cat /etc/rc.conf
ctld_enable="YES"
zfs_enable="YES"

# /etc/rc.d/ctld start
Starting ctld.

# ctladm devlist -v
LUN Backend       Size (Blocks)   BS Serial Number    Device ID
  0 block              41943040  512 MYSERIAL0000     MYDEVID0000
      lun_type=0
      num_threads=32
      vendor=FreeBSD
      file=/dev/zvol/pool0/zvol0
      ctld_name=iqn.2023-12.iscsi.org.seichan:target0,lun,0
      scsiname=iqn.2023-12.iscsi.org.seichan:target0,lun,0
  1 block               2621440 4096 MYSERIAL0001     MYDEVID0001
      lun_type=0
      num_threads=32
      vendor=FreeBSD
      file=/pool0/lun1.img
      ctld_name=iqn.2023-12.iscsi.org.seichan:target0,lun,1
      scsiname=iqn.2023-12.iscsi.org.seichan:target0,lun,1

iSCSI 用のボリュームを ZFS で作成する利点は上でも書いていますが，ZFS の機能を利用できる事です．

スナップショットの作成，クローン，send / recv によるレプリケーションはもちろん，圧縮や重複排除が利用できます．

もちろん，ボリュームを作成して iSCSI で．ではなく，ZFS ファイルシステムを NFS で提供ということも可能ですし，こちらも同様の利点があります．

最終的には利用するシステムがどちらの方が都合がよいのか (パフォーマンスの観点，扱いやすさの観点など色々とあると思います) で選択で良いでしょう．

自分の場合は ZFS ファイルサーバー側でファイルが読み書きできる方を重要視しているので iSCSI の利用ではなく NFS での利用を行っていますが，MSFC の検証などでは iSCSI を利用しています．

以上，ブロックデバイスとして切り出す紹介を終わります．次回は圧縮と重複排除について触れていこうと思います．

FreeBSD で ZFS を利用する – send/recv を使い倒す

seichan — Thu, 21 Dec 2023 13:00:00 +0000

前回は ZFS ファイルシステムを色々使ってみて最後にクローンを行った所まで実施しました．
今回はプール間のクローン・レプリケーション技術の send / recv に焦点を絞って説明を行っていきます．

ZFS に関するお話

今回は自ホスト内(ローカル)のプール間クローンと，ホスト間のプール間クローンの二種を扱っていきます．
構成はこんな感じの環境を用意しました．

前回は pool0/data を pool1 にクローンしました．おさらいとして改めて以下に記載します．

ローカル内のプール間クローン
1. 前回のおさらい
バックアップとしてのクローン戦略
1. 初回バックアップ
2. 増分バックアップを行っていく
  1. 途中のスナップショットは維持しない
  2. スナップショットを維持したままクローンする
ホスト間のクローン
番外編 (ZFS クローンをファイルとして保存する)
1. ファイルに書き出す (バックアップ)
2. ファイルから書き戻す (リストア)

ローカル内のプール間クローン

前回のおさらい

別プールに作成する場合は zfs send と zfs recv を利用します．

# zfs send pool0/data@snap-9 | zfs recv pool1/clone

# zfs list
NAME               USED  AVAIL     REFER  MOUNTPOINT
pool0             10.0G   375G     32.0K  /pool0
pool0/data        53.3K  10.0G     34.0K  /data
pool0/data-clone     0B   375G     34.0K  /pool0/data-clone
pool0/share       30.6K   385G     30.6K  /pool0/share
pool1              154K  96.4G       24K  /pool1
pool1/clone       26.5K  96.4G     26.5K  /pool1/clone

pool1 に clone というファイルシステムが無事作成されました．この中身を見てみましょう．

# ls /pool1/clone
data1.txt       data2.txt       data3.txt

# zfs list -t snapshot pool1/clone
NAME                 USED  AVAIL     REFER  MOUNTPOINT
pool1/clone@snap-9     0B      -     26.5K  -

このようにデータはクローンされています．スナップショットも指定した物がクローン先に残っています．
これは zfs clone と zfs send / recv での動きが違うためとなります．
スナップショットは不必要であれば削除してもらっても大丈夫です．

バックアップとしてのクローン戦略

初回バックアップなど，全体をまずはクローン/レプリケーションしたい場合は先にも書いたような方法となります．
特定のスナップショットを指定して zfs send で送信，zfs recv で受信させます．

次のような環境 (スナップショットは全部消しました) からバックアップとして取るには．を改めて解説していきます．

# zfs list
NAME          USED  AVAIL     REFER  MOUNTPOINT
pool0        10.0G   375G     30.6K  /pool0
pool0/data   34.0K  10.0G     34.0K  /data
pool0/share  30.6K   385G     30.6K  /pool0/share
pool1         154K  96.4G       24K  /pool1

# zfs list -t snapshot
no datasets available

初回バックアップ

初回バックアップについては特にありません．一番最初に持っていきたい状態のスナップショットを指定する形になります．例えば次のようなスナップショット状況の場合があったとします．

# zfs list -t snapshot
NAME                    USED  AVAIL     REFER  MOUNTPOINT
pool0/data@2023120110     0B      -     34.0K  -
pool0/data@2023120112     0B      -     34.0K  -
pool0/data@2023120114     0B      -     34.0K  -
pool0/data@2023120116     0B      -     34.0K  -
pool0/data@2023120118     0B      -     34.0K  -
pool0/data@2023120120     0B      -     34.0K  -
pool0/data@2023120122     0B      -     34.0K  -

どの時点でもいいです．であればどの時点を指定してもらっても構いません．今回は一番最初の時点のスナップショットを起点として実施してみます．

# zfs send pool0/data@2023120110 | zfs recv pool1/data-backup

# zfs list
NAME                USED  AVAIL     REFER  MOUNTPOINT
pool0              10.0G   375G     30.6K  /pool0
pool0/data         34.0K  10.0G     34.0K  /data
pool0/share        30.6K   385G     30.6K  /pool0/share
pool1               184K  96.4G       24K  /pool1
pool1/data-backup  26.5K  96.4G     26.5K  /pool1/data-backup

# zfs list -t snapshot pool1/data-backup
NAME                           USED  AVAIL     REFER  MOUNTPOINT
pool1/data-backup@2023120110     0B      -     26.5K  -

これは何度も言いますが先の説明となんら変更はありません．

増分バックアップを行っていく

大事なのはここからになります．
2回目以降は全部をクローンするのではなく，変更点のみをクローンで転送ができればかかる転送量と時間を節約できます．

変更点を転送する場合も zfs send を用いますがオプションが追加されます．

途中のスナップショットは維持しない

増分のクローンにおいて，最終状態のみ保持出来ればよいという場合は途中のスナップショットがクローン側に存在する必要はありません．そのような場合は次のコマンドになります．

# zfs send -i pool0/data@2023120110 pool0/data@2023120122 | zfs recv pool1/data-backup

# zfs list -t snapshot pool1/data-backup
NAME                           USED  AVAIL     REFER  MOUNTPOINT
pool1/data-backup@2023120110     0B      -     26.5K  -
pool1/data-backup@2023120122     0B      -     26.5K  -

初回に送ったスナップショット (正確には zfs send で前回送信したスナップショット) と，次に送りたいスナップショットを指定することで，その間の変更点のみと指定できます．

-i オプションはその間のスナップショットを含まない．になりますので，受け側は初回と2回目のスナップショットのみが保存されている状態となります．

毎日これが継続するとした場合で翌日のスナップショット状況がこうなっていたとします．

# zfs list -t snapshot pool0/data
NAME                    USED  AVAIL     REFER  MOUNTPOINT
pool0/data@2023120110     0B      -     34.0K  -
pool0/data@2023120112     0B      -     34.0K  -
pool0/data@2023120114     0B      -     34.0K  -
pool0/data@2023120116     0B      -     34.0K  -
pool0/data@2023120118     0B      -     34.0K  -
pool0/data@2023120120     0B      -     34.0K  -
pool0/data@2023120122     0B      -     34.0K  -
pool0/data@2023120200     0B      -     34.0K  -
pool0/data@2023120202     0B      -     34.0K  -
pool0/data@2023120204     0B      -     34.0K  -
pool0/data@2023120208     0B      -     34.0K  -
pool0/data@2023120210     0B      -     34.0K  -
pool0/data@2023120212     0B      -     34.0K  -
pool0/data@2023120214     0B      -     34.0K  -
pool0/data@2023120216     0B      -     34.0K  -
pool0/data@2023120218     0B      -     34.0K  -
pool0/data@2023120220     0B      -     34.0K  -
pool0/data@2023120222     0B      -     34.0K  -

前回送信した際の終了点は「pool0/data@2023120122」ですので今回の起点が「pool0/data@2023120122」になります．そこからの差分の最新点の「pool0/data@2023120222」までを送りたい場合は次のようになります．

# zfs send -i pool0/data@2023120122 pool0/data@2023120222 | zfs recv pool1/data-backup

# zfs list -t snapshot pool1/data-backup
NAME                           USED  AVAIL     REFER  MOUNTPOINT
pool1/data-backup@2023120110     0B      -     26.5K  -
pool1/data-backup@2023120122     0B      -     26.5K  -
pool1/data-backup@2023120222     0B      -     26.5K  -

このように，前回送ったスナップショットおよび新しく送りたいスナップショットを指定することで例えば毎日バックアップを行うということが可能になります．

この例では日付・時間をスナップショット名としましたが，バックアップの為の専用のスナップショット名を用いるなどをする方がスクリプト化はしやすいかと思います．

スナップショットを維持したままクローンする

維持の必要の有無はバックアップの用途によりますが，メインと同じ状態を維持したいというケースも当然あります．そんな場合でも対応可能です．
初回のクローンが完了しており，2回目以降のクローンを行う所から記載します．
(先の維持しないクローンの状態をクリアした所から実施していますので混乱しないでください)

# zfs send -I pool0/data@2023120110 pool0/data@2023120122 | zfs recv pool1/data-backup

# zfs list -t snapshot pool1/data-backup
NAME                           USED  AVAIL     REFER  MOUNTPOINT
pool1/data-backup@2023120110     0B      -     26.5K  -
pool1/data-backup@2023120112     0B      -     26.5K  -
pool1/data-backup@2023120114     0B      -     26.5K  -
pool1/data-backup@2023120116     0B      -     26.5K  -
pool1/data-backup@2023120118     0B      -     26.5K  -
pool1/data-backup@2023120120     0B      -     26.5K  -
pool1/data-backup@2023120122     0B      -     26.5K  -

実際はオプションを -i から -I に変えただけですが，これによって間のスナップショットも維持したままクローンが行われます．

翌日にも同様に増分をクローンした場合はこのようになります．

# zfs send -I pool0/data@2023120122 pool0/data@2023120222 | zfs recv pool1/data-backup

# zfs list -t snapshot pool1/data-backup
NAME                           USED  AVAIL     REFER  MOUNTPOINT
pool1/data-backup@2023120110     0B      -     26.5K  -
pool1/data-backup@2023120112     0B      -     26.5K  -
pool1/data-backup@2023120114     0B      -     26.5K  -
pool1/data-backup@2023120116     0B      -     26.5K  -
pool1/data-backup@2023120118     0B      -     26.5K  -
pool1/data-backup@2023120120     0B      -     26.5K  -
pool1/data-backup@2023120122     0B      -     26.5K  -
pool1/data-backup@2023120200     0B      -     26.5K  -
pool1/data-backup@2023120202     0B      -     26.5K  -
pool1/data-backup@2023120204     0B      -     26.5K  -
pool1/data-backup@2023120208     0B      -     26.5K  -
pool1/data-backup@2023120210     0B      -     26.5K  -
pool1/data-backup@2023120212     0B      -     26.5K  -
pool1/data-backup@2023120214     0B      -     26.5K  -
pool1/data-backup@2023120216     0B      -     26.5K  -
pool1/data-backup@2023120218     0B      -     26.5K  -
pool1/data-backup@2023120220     0B      -     26.5K  -
pool1/data-backup@2023120222     0B      -     26.5K  -

ホスト間のクローン

先ほどまでは同一ホスト内でのクローンを行っていました．遠隔地のバックアップを実施したいなどホスト間のクローンを持ちたいケースは多いと思います．
ここでは，ホスト間のクローンについて説明します．

環境整備

ホスト間ですので，基本はネットワーク経由になります．方法は RSH や SSH などになりますが，WAN を超えた場合を想定して SSH での zfs send / recv を例に環境の整備の例を記載します．

送信側の SSH の準備

cron などで実施することが想定されるため，公開鍵認証でパスフレーズ無しで行うことになると思います．
ですので，その準備を行います．

# ssh-keygen -f /root/.ssh/zfs
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/zfs
Your public key has been saved in /root/.ssh/zfs.pub
The key fingerprint is:
SHA256:t7h8H2HD5dYDEQHR/syNOOjNOe1uMEKTz356TyduHzo root@bsd13-1.seichan.local
The key's randomart image is:
+---[RSA 3072]----+
|           o++o  |
|             ..  |
|           ....  |
|          +. +.. |
|        S..==.*oo|
|         oooB+.+o|
|        ...=.*..o|
|       . .o *EBoo|
|        o. .o@=oo|
+----[SHA256]-----+

ZFS で使用するための鍵として /root/.ssh/zfs を指定しました．受け側に渡す公開鍵は /root/.ssh/zfs.pub になります．公開鍵を受け側ホストに設定をしていきます．

受信側の SSH の準備

送信側の公開鍵を /root/.ssh/authorized_keys にセットします．

echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDxXlxhbPVYeu7afXOuOjl6imlbZ23HiCiyktSUGb1liOtJOTK0xKqMkOX3d03UJP43GZW1B8ASHaMV0MJj0gVaSv54mN5Kwi7cczKYVfVs5SsLNieLgclTZ3Hes7qbFmxH5+FrSccsJFrcjs4Mjdhdn6UBzPwNDll9Y/YHWCdGcwUiAvfJJZQH+K88A8X/Yv0kGNF82kuQE7xjW+GQPYfhTFMaFEPZF/tfiI55VxevdDoox52CaHFWrEIDPQHRmrrxvU3dcR88bpdKhO/8CnI7vbOYmfi5OYBOVJJ+5l9YWih9pEBhofBvrrhP5rB0C4O5jhojfv2F+lG0MkDep4AwcrpgQ8EQlahbKozJ8pdE1VDDEYkzCaE1yJzY8R6o5QFSXcSocBBQpMnLde1EiaMVP/w1e3p4OMhAMlUi3MkdtXLDT1r6r98v3KiQEp/ZQCfSnvrEapO0E5LCco00yoUY6uxu5XPi2pLTjcLFcucQQGxQiJfzdhAK4+kEAqUu3nU= root@bsd13-1" >> /root/.ssh/authorized_keys

その後，鍵を利用してパスフレーズ無しでログインができることを確認します．

root@bsd13-1:~ # ssh -i /root/.ssh/zfs root@192.168.241.43
The authenticity of host '192.168.241.43 (192.168.241.43)' can't be established.
ED25519 key fingerprint is SHA256:UfCmkkApPp8jkMDabQUvzazpTuIzbK8LOxaUqtMVQYg.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.241.43' (ED25519) to the list of known hosts.
Last login: Wed Dec 20 10:03:51 2023 from 192.168.241.192
FreeBSD 13.2-RELEASE releng/13.2-n254617-525ecfdad597 GENERIC

Welcome to FreeBSD!

root@bsd13-2:~ #

受信側の ZFS プールの準備

受信側の ZFS プールを作成します．詳細な手順は省いていますので「FreeBSD で ZFS を利用する – ZFS プールの作成」を参照ください．

# zpool create pool0 da1

# zpool status
  pool: pool0
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        pool0       ONLINE       0     0     0
          da1       ONLINE       0     0     0

errors: No known data errors

初回バックアップ

ローカルとの違いは特にありません．一番最初に持っていきたい状態のスナップショットを指定する形になります．先に使用した環境ですので，持っているスナップショットの状態はこのような所から実施していきます．

# zfs list -t snapshot pool0/data
NAME                    USED  AVAIL     REFER  MOUNTPOINT
pool0/data@2023120110     0B      -     34.0K  -
pool0/data@2023120112     0B      -     34.0K  -
pool0/data@2023120114     0B      -     34.0K  -
pool0/data@2023120116     0B      -     34.0K  -
pool0/data@2023120118     0B      -     34.0K  -
pool0/data@2023120120     0B      -     34.0K  -
pool0/data@2023120122     0B      -     34.0K  -
pool0/data@2023120200     0B      -     34.0K  -
pool0/data@2023120202     0B      -     34.0K  -
pool0/data@2023120204     0B      -     34.0K  -
pool0/data@2023120208     0B      -     34.0K  -
pool0/data@2023120210     0B      -     34.0K  -
pool0/data@2023120212     0B      -     34.0K  -
pool0/data@2023120214     0B      -     34.0K  -
pool0/data@2023120216     0B      -     34.0K  -
pool0/data@2023120218     0B      -     34.0K  -
pool0/data@2023120220     0B      -     34.0K  -
pool0/data@2023120222     0B      -     34.0K  -

この中の一番最初のスナップショットを起点に初回のクローンを行ってみます．

送信側はこのように，パイプの後に SSH を実行させ，コマンドとして zfs recv を実行する形で行います．

root@bsd13-1:~ # zfs send pool0/data@2023120110 | ssh -i /root/.ssh/zfs root@192.168.241.43 "zfs recv pool0/data-backup"

受信側でどのようになっているかを確認します．指定したファイルシステムが作成されたことと，スナップショットが存在している事が確認できます．

# cd
root@bsd13-2:~ # zfs list
NAME                USED  AVAIL     REFER  MOUNTPOINT
pool0               154K  96.4G       24K  /pool0
pool0/data-backup  26.5K  96.4G     26.5K  /pool0/data-backup

# zfs list -t snapshot pool0/data-backup
NAME                           USED  AVAIL     REFER  MOUNTPOINT
pool0/data-backup@2023120110     0B      -     26.5K  -

ホスト間の増分バックアップを行っていく

大事なのはここからになります．
ホスト間であればなおさら2回目以降は全部をクローンするのではなく，変更点のみを送信したいと思います．

実行するコマンドはホスト内のクローンと同様です．SSH 経由で実行するのが違いとなります．

途中のスナップショットは維持しない

# zfs send -i pool0/data@2023120110 pool0/data@2023120122 | ssh -i /root/.ssh/zfs root@192.168.241.43 "zfs recv pool0/data-backup"

# zfs list -t snapshot pool0/data-backup
NAME                           USED  AVAIL     REFER  MOUNTPOINT
pool0/data-backup@2023120110     0B      -     26.5K  -
pool0/data-backup@2023120122     0B      -     26.5K  -

# zfs send -i pool0/data@2023120122 pool0/data@2023120222 | ssh -i /root/.ssh/zfs root@192.168.241.43 "zfs recv pool0/data-backup"

# zfs list -t snapshot pool0/data-backup
NAME                           USED  AVAIL     REFER  MOUNTPOINT
pool0/data-backup@2023120110     0B      -     26.5K  -
pool0/data-backup@2023120122     0B      -     26.5K  -
pool0/data-backup@2023120222     0B      -     26.5K  -

このように，ローカル間でもホスト間でも実施の方式に大きな違いが無く出来ることが理解できたかと思います．

スナップショットを維持したままクローンする

# zfs send -I pool0/data@2023120110 pool0/data@2023120122 | ssh -i /root/.ssh/zfs root@192.168.241.43 "zfs recv pool0/data-backup"

# zfs list -t snapshot pool0/data-backup
NAME                           USED  AVAIL     REFER  MOUNTPOINT
pool0/data-backup@2023120110     0B      -     26.5K  -
pool0/data-backup@2023120112     0B      -     26.5K  -
pool0/data-backup@2023120114     0B      -     26.5K  -
pool0/data-backup@2023120116     0B      -     26.5K  -
pool0/data-backup@2023120118     0B      -     26.5K  -
pool0/data-backup@2023120120     0B      -     26.5K  -
pool0/data-backup@2023120122     0B      -     26.5K  -

実際はオプションを -i から -I に変えただけですが，これによって間のスナップショットも維持したままクローンが行われます．

翌日にも同様に増分をクローンした場合はこのようになります．

# zfs send -I pool0/data@2023120122 pool0/data@2023120222 | ssh -i /root/.ssh/zfs root@192.168.241.43 "zfs recv pool0/data-backup"

# zfs list -t snapshot pool0/data-backup
NAME                           USED  AVAIL     REFER  MOUNTPOINT
pool0/data-backup@2023120110     0B      -     26.5K  -
pool0/data-backup@2023120112     0B      -     26.5K  -
pool0/data-backup@2023120114     0B      -     26.5K  -
pool0/data-backup@2023120116     0B      -     26.5K  -
pool0/data-backup@2023120118     0B      -     26.5K  -
pool0/data-backup@2023120120     0B      -     26.5K  -
pool0/data-backup@2023120122     0B      -     26.5K  -
pool0/data-backup@2023120200     0B      -     26.5K  -
pool0/data-backup@2023120202     0B      -     26.5K  -
pool0/data-backup@2023120204     0B      -     26.5K  -
pool0/data-backup@2023120208     0B      -     26.5K  -
pool0/data-backup@2023120210     0B      -     26.5K  -
pool0/data-backup@2023120212     0B      -     26.5K  -
pool0/data-backup@2023120214     0B      -     26.5K  -
pool0/data-backup@2023120216     0B      -     26.5K  -
pool0/data-backup@2023120218     0B      -     26.5K  -
pool0/data-backup@2023120220     0B      -     26.5K  -
pool0/data-backup@2023120222     0B      -     26.5K  -

いかがでしょうか．スナップショットを維持する・しないにかかわらず，ホスト内・ホスト間の ZFS クローンが簡単にできることが分かったかと思います．

番外編 (ZFS クローンをファイルとして保存する)

番外編という書き方にしていますが，外部メディアにバックアップとして保存するためにイメージをファイルに保存するということも可能です．
ファイルに保存の他，直接テープに書きだしたり DVD/BD に書きだすこともやりようによっては可能です．

ファイルに書き出す (バックアップ)

ここでは，ファイルに書き込む形を紹介します．
(元データは pool1/data で，書き出す先は pool1 の中に置きます)

# zfs send pool0/data@2023120110 > /pool1/pool0_data@2023120110.img

リダイレクトを使ってファイルに出力をしています．拡張子はなんでもよいのですが，イメージファイルですので .img を拡張子としました．
このような形でファイルに書き出すことが可能です．

増分も同様です．間のスナップショット込みの情報をファイルに書き出す場合は以下のとおりです．

# zfs send -I pool0/data@2023120110 pool0/data@2023120122 > /pool1/pool0_data@2023120110-data@2023120122.img

いかがでしょうか．コマンドはほぼ変わらずにファイルに書き出すことを実現できています．

ファイルから書き戻す (リストア)

ファイルに書き出したイメージファイルをもとにファイルシステムを復元してみます．
ここでは pool0/data-restore として復元してみます．

# cat /pool1/pool0_data@2023120110.img | zfs recv pool0/data-restore

# zfs list
NAME                 USED  AVAIL     REFER  MOUNTPOINT
pool0               10.0G   375G     32.0K  /pool0
pool0/data          34.0K  10.0G     34.0K  /data
pool0/data-restore  34.0K   375G     34.0K  /pool0/data-restore
pool0/share         30.6K   385G     30.6K  /pool0/share
pool1                330K  96.4G     82.5K  /pool1
pool1/data-backup   26.5K  96.4G     26.5K  /pool1/data-backup

# zfs list -t snapshot pool0/data-restore
NAME                            USED  AVAIL     REFER  MOUNTPOINT
pool0/data-restore@2023120110     0B      -     34.0K  -

このように，イメージファイルを読み込み，zfs recv に渡すことでリストアすることができます．

増分データも同様にリストアすることが可能です．

# cat /pool1/pool0_data@2023120110-data@2023120122.img | zfs recv pool0/data-restore

# zfs list -t snapshot pool0/data-restore
NAME                            USED  AVAIL     REFER  MOUNTPOINT
pool0/data-restore@2023120110     0B      -     34.0K  -
pool0/data-restore@2023120112     0B      -     34.0K  -
pool0/data-restore@2023120114     0B      -     34.0K  -
pool0/data-restore@2023120116     0B      -     34.0K  -
pool0/data-restore@2023120118     0B      -     34.0K  -
pool0/data-restore@2023120120     0B      -     34.0K  -
pool0/data-restore@2023120122     0B      -     34.0K  -

と，このように増分データのリストアも可能です．

先に紹介したホスト間クローンの時に，相手先が ZFS ではない場合はこのようにファイルとして書き出すことでリモートへのバックアップを行う．ということが可能になります．

以上，zfs send / recv の紹介でした．質問があればコメント欄で質問頂ければと思います．