ドキュメントとメディアが混在する場合のZFSデータセットのrecordsize設定方法

混在するドキュメントとメディア向けにZFSデータセットのrecordsizeを設定する際は、ファイル拡張子ではなくアクセスパターンに合わせ、ライブ共有を再構築する前に新規書き込みで変更をテストしてください。

ホームNASでは、ドキュメント、スキャン、写真、動画、アーカイブ、アプリケーションのエクスポートデータが、1つの便利な共有に保存されることがよくあります。しかし、その利便性の裏には異なるI/Oパターンが隠れています。そのため、recordsizeを決める際は、保守的な混在向け設定を使うか、読み書きの特性が明確に異なるワークロードごとにデータセットを分けるのが最も安全です。

データセットが本当に混在しているか確認する

まず、データセットに実際に何が保存され、クライアントがどのように利用しているかを確認します。「Media」という名前のフォルダーにも、サムネイル、字幕ファイル、プロジェクトファイル、小さなドキュメントが含まれている場合があります。一方、「Documents」共有に大容量のPDFスキャンや圧縮アーカイブが含まれることもあります。

OpenZFSではrecordsizeをデータセットプロパティとして説明しており、一般的なアクセスパターンにはZFSが内部アルゴリズムを自動的に使用する一方、特別なチューニングが特に有効なのは、アプリケーションが大容量ファイルを固定サイズのレコードでアクセスする場合だと記載しています。

データセットが本当に混在していて、すでに十分な性能が出ているなら、別のガイドで大きな値が推奨されているという理由だけでrecordsizeを変更するのは避けてください。最初に判断すべきなのは、現在の問題が実在するかどうかです。低速なメディアのシーケンシャル読み取り、小さなファイルの応答性低下、バックアップの負荷増大が起きているのか、それとも理論上のチューニング懸念にすぎないのかを確認します。

アクセスパターンが明確に分かれる場合はデータセットを分ける

recordsizeはデータセット単位で適用されるため、そのデータセットに新しく書き込まれるすべてのファイルで1つの設定を共有する必要があります。大容量メディアと頻繁に変更される小さなドキュメントを同じ場所に保存すると、1つの値が一方のワークロードには役立つ一方で、もう一方の予測可能性を損なう可能性があります。

Klara Systemsは、OpenZFSのrecordsizeプロパティがデータセット内のファイルに対する最大論理ブロックサイズを設定し、zvolでは代わりにvolblocksizeを使用すると説明しています。このデータセット単位の適用範囲が、万能な数値を追い求めるよりもワークロードを分割する方がすっきりする理由です。

大容量のシーケンシャル読み書きが中心ならメディア向けデータセットを作成し、ファイルが小さく頻繁に編集される、または多数のクライアントで同期される場合は、ドキュメント用データセットを保守的な設定にします。まだデータを移動せず、まず新しいファイルでテストしてください。

影響を与えたいデータを書き込む前にrecordsizeを変更する

recordsizeの変更は、既存ファイルのレイアウトを自動的に書き換える魔法のような機能ではありません。変更後の新しい書き込みでどのように領域が割り当てられるかに影響するため、共有が満杯になった後でプロパティを変更しても、ファイルを書き換えるか置き換えるまで十分な検証にはなりません。

OpenZFSのzfspropsマニュアルは、データベースチューニングの文脈でrecordsizeを汎用ファイルシステムに使用することを強く推奨していません。これは、recordsizeを万能な性能調整機能として扱うべきではないという重要な注意点です。

新しいデータセットでは、データをコピーする前に意図した値を設定します。既存のデータセットでは、候補となる設定で新しいデータセットを作成し、代表的なフォルダーをそこへコピーしてテストします。そのうえで、閲覧速度、バックアップの挙動、クライアントの応答性を比較してから、書き換えを計画してください。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

用途が不明確な混在共有には保守的なデフォルトを選ぶ

ワークロードが明確でない場合、積極的なチューニングよりも保守的なデフォルトの方が通常は安全です。目的はベンチマークの数値を最大化することではなく、頻繁ではあるものの見落とされがちなアクセスパターンに不利な設定を作らないことです。

OracleのZFS管理ガイドは、recordsizeを推奨ブロックサイズとして説明し、データベースワークロードを主な用途として強調しています。これは、一般的な混在ファイル共有では慎重に扱うべきだという考えを裏付けています。

まだワークロードを分離できない場合は、混在データセットをプラットフォームのデフォルト、またはストレージディストリビューションが推奨する控えめな値のままにします。そして共有のアーカイブ全体をその場で変更するのではなく、大容量メディア用に別のテストデータセットを作成してください。

プール統計だけでなく実際のクライアント動作で検証する

最後に確認すべきなのは、実際に共有を利用するデバイスから見た動作です。プール全体のスループットが良好でも、アクセスパターンが変化したことで、写真アプリ、ドキュメント同期クライアント、バックアップジョブの速度が低下することがあります。

メディアおよびドキュメントデータセットに関するコミュニティのZFS議論では、recordsizeをcompression、atime、xattrsなどの他のプロパティと分けて考えることがよくあります。これは、recordsizeがワークロードとの適合性を決める要素の1つにすぎないためです。

普段行っているコピー、閲覧、編集、スキャン、バックアップの作業を同じように実行します。変更のきっかけとなったワークロードが改善し、重要なクライアントの性能が低下していない場合にのみ新しい設定を維持してください。それ以外の場合は、以前の設定を使うデータセットへ今後のデータを書き込むことで元に戻します。

よくある質問

recordsizeを変更すると、既存ファイルはすぐに書き換えられますか？

いいえ。変更は新しい書き込みに影響すると考えてください。公平に評価するには、新しくコピーした代表的なデータでテストするか、設定を決めた後に計画的な書き換えを実施します。

メディアには常に利用可能な最大のrecordsizeを使うべきですか？

いいえ。大容量のシーケンシャルメディアでは大きなレコードが有効な場合がありますが、サムネイル、プロジェクトファイル、メタデータ、字幕、混在したアクセスによって結果は変わります。画一的なルールを適用する前に、実際のデータセットでテストしてください。

recordsizeの問題から、より大きな整理上の問題が明らかになった場合は、まずワークロードを分離してください。これは、スナップショットレプリケーションによって宛先プールが満杯になるのを防ぐ際にも使われる、同じデータセット境界の考え方です。