Share FreeBSD based information

ファイルシステムの選び方 - [メリット] 14. ...

yuichiro@undisclosed.example.com (yuichiro) — Mon, 22 Apr 2024 00:45:08 +0000

ファイルシステムの選び方

FreeBSD でハードディスク(またはSSD)を使用する場合、 UFS または ZFS のファイルシステムを選ぶことができます。

UFS はその名の通り UNIX で使われてきた伝統的なファイルシステムの後継であり、時代に合わせて扱える容量や性能を改善したファイルシステムです。

ZFS はもともと Sun Microsystems が開発した次世代のファイルシステムで多数のハードディスクを効率的に運用できるように設計されました。

それぞれ次のようなメリット・デメリットがあります。

UFS

メリット

ZFS と比較して少ないメモリで動作する
今までの UNIX のハードディスクの運用知見が活かせる
スナップショット機能 (*1)
ジャーナリング機能 (*1)
POSIX.1e ACL サポート
NFS v4 ACL サポート
TRIM サポート

*1: 14.0 からスナップショットとジャーナリングの両方を同時に選択可能。14.0 より前の版ではどちらか一つのみ使用可能。

デメリット

ファイルシステムの容量はディスクパーティションに依存する
冗長構成は GEOM またはハードウェア任せ
データのチェックサムがない
メタデータのチェックサムは 13.0 以降でサポート予定

ZFS

メリット

パーティションにとらわれずに柔軟にファイルシステムのサイズを変更できる
全てのデータ、メタデータがチェックサムで検証される
効率的なキャッシュ機能 (ARC: adaptive replacement cache)
ストライプ, ミラー, RAID-Z などの冗長構成をファイルシステムレベルでサポートしている
RAID-Z によるサイレントクラッシュ防止機能
圧縮機能
スナップショット機能
スナップショットからクローンを作成する機能
広大なディスク領域を管理できる(最大 16エクサ=2^64 バイトのファイルシステムが構築可能)
スナップショットとクローンを合わせてルートファイルシステムを任意に切り替えられる (boot environment)
NFS v4 ACL サポート
TRIM サポート

デメリット

メモリ使用量が大きい (搭載メモリ 4GB 以上を推奨)
キャッシュミス時のペナルティが大きい
UFS と扱いが大きく異なるため UFS の運用知見が通用しない
POSIX.1e ACL のサポートがない

どちらを選ぶべきか

FreeBSD を動かすマシンの搭載メモリが少ない(4GB未満)ならば UFS を選ぶべきです。 ZFS を動かすこともできますが、おそらく期待するような性能は得られないでしょう。

また、伝統的な UNIX のハードディスク管理に慣れており、歴史的な経緯や過去の経験からあまり運用を変えたくないのであれば UFS を選択するべきです。

アプリケーションに多くのメモリを割り当てたい場合も UFS の方が良いでしょう。 ZFS は ARC に大量のメモリを使用します。その分アプリケーションに割り当てられるメモリが少なくなるため、例えば memcached サーバのような用途には UFS が適しています。

メモリがそれなりに搭載できるならば(4GB〜)、ZFS を選ぶこともできます。たとえハードディスクが1本しかなくても、ZFS のメリットが魅力的に思えるようならば十分に ZFS を選ぶ理由になることでしょう。例えば、圧縮機能はディスクアクセス量を減らし見た目のスループットを向上させます。また、ARCにも圧縮されたデータが乗るため、見た目のキャッシュサイズも増大することになります。

多数のハードディスク(3〜4本以上)を扱うならば、ZFS は魅力的な選択肢になるでしょう。冗長構成を組んだ状態から任意にファイルシステムのサイズ割り当てを変えられるため、より効率的にディスク容量を管理することができます。

データベースのようにアプリケーションにも多くのメモリを割り当てかつ、ハードディスクの管理を楽に行いたいような場合は一概にどちらが良いかを判断することはできません。実際にベンチマークをとって選ぶべきだと思います。

10Gbps のパケット転送 - [FIB algorithm]

seirios@undisclosed.example.com (seirios) — Thu, 02 Nov 2023 10:22:16 +0000

10Gbps のパケット転送

10Gbps の NIC を挿してパケット転送をなるべく高速に行う際のポイントについて列挙します。

FIB algorithm

FreeBSD 13.0 から Fib の検索アルゴリズムが変わりました。 options FIB_ALGO を付けてカーネルをビルドすると sysctl で次のように検索アルゴリズムを表示・選択できるようになります。

net.route.algo.debug_level: 5
net.route.algo.inet.algo: bsearch4
net.route.algo.inet.algo_list: bsearch4, radix4_lockless, radix4
net.route.algo.inet6.algo: radix6_lockless
net.route.algo.inet6.algo_list: radix6_lockless, radix6
net.route.algo.fib_max_sync_delay_ms: 1000
net.route.algo.bucket_change_threshold_rate: 500
net.route.algo.bucket_time_ms: 50

デフォルトで IPv4 はロックのかかるアルゴリズムになっていますので、経路表のエントリ数が多い(1万以上?)場合には lockless のアルゴリズムを選びましょう。このあたりは、経路数、経路の更新頻度や通信量（経路表参照回数)に依存する部分なので、どれが良いとは一概に言えませんが、経路数が多いならば、bsearchよりRadix系を選択する方が良いことが多いと言えます。

Lockless: bsearch4, radix[46]_lockless
Lockあり: radix[46]

なお、FreeBSD-13.2-RELEASE 及び、FreeBSD-14.0-RELEASEでは Options FIB_ALGO は GENERIC カーネルに入っています。

また、手元で確認した限りでは、FreeBSD-13.2以降は、IPv4 が bsearch4、IPv6ではradix6_locklessが標準となっています。

RSS (Receive Side Scaling)

Receive Side Scaling を有効にするには以下の全てを満たす必要があります。

multi-queue を持つ NIC を用意すること
該当ドライバが multi-queue を扱えること
`Options RSS` を付けてビルドしたカーネルであること
sysctl net.isr.maxthreads に NICの持つ queue 以上の数を指定すること (-1 で CPU Core数と同じ数になります）
sysctl net.isr.bindthreads=1 を指定すること

なお、FreeBSD-13.2-RELEASE/14.0-RELEASEでは、GENERIC kernelにはRSSは含まれていません。必要に応じてkernelをbuildする必要があります。

TSO & LRO

10Gbps の NIC にはほとんどの場合、TSO (TCP Segment Offload) や LRO (Large Receive Offload) の機能がついています。これらは大きなデータを転送する際にパケットの分割、統合を NIC 側で行ってくれるものです。ルータとして構築する場合、TSO/LROはoffにするべきです。中継段でのパケットの再構成、分割を行うことは望ましくありません。

ifconfig のオプションに -tso -lro -vlanhwtso を付けておきます。

FreeBSD 12系以前の話

sysctl net.inet.ip.redirect=0 を設定すると fast forwarding するようになり高速にパケット転送されます。

これは、12系以前では net.inet.ip.redirect=1 （デフォルト）だと fast forwarding のコードパスを通らないためです。

以下の commit でこの動作が変更されました。

https://cgit.freebsd.org/src/commit/?id=f389439f50fc4c27d15d3017b622270e25ba71c7

IPv6 を転送する時には同様に net.inet6.ip6.redirect=0 を設定します。

FreeBSD マシンの引っ越し - [新しい環境で起動する] host id ...

yuichiro@undisclosed.example.com (yuichiro) — Wed, 09 Aug 2023 01:04:38 +0000

FreeBSD マシンの引っ越し

Boot Environment を使っているならば、新しいマシンへ簡単に環境を移すことができます。

単に古いマシンの default 環境を新しいマシンの new 環境にコピーし、new 環境から起動するだけです。

以下、古いマシンを old_host 、新しいマシンを new_host として、具体的な手順を示します。

セットアップ

まず、新しいマシンに zfs root で FreeBSD をインストールします。この時、古いマシンと同じバージョンの FreeBSD か、より新しいバージョンの FreeBSD を選びます。新しいマシンの設定はネットワークに接続できる最小限の設定で構いません。 ports / pkg のインストールも不要です。ユーザも作る必要はありません。（どのみち root で作業しますので）

そして、古いマシンと新しいマシンをネットワークに接続します。 IP アドレスやデフォルトルート等は環境に合わせて、適切に設定してください。

コピー

新しいマシン側では new 環境に対して zfs recv を行います。

new_host# nc -l 9999 | zfs recv zroot/ROOT/new

古いマシン側では default 環境にタグをつけた上でそれを zfs send します。

old_host# zfs snapshot zroot/ROOT/default@current
old_host# zfs send -L -c zroot/ROOT/default@current | nc -N new_host 9999
old_host# zfs destroy zroot/ROOT/default@current

最近の zfs では large blocks と圧縮をサポートしていますので、 zfs send に -L と -c をつけておくと良いでしょう。

もし、ネットワークが不安定で一度の send で送れないようでしたら、 send & recv のレジュームを試してみてください。

古いホストを停止する

コピーが完了したら古いホストを停止します。新しいホストは設定を含めて何もかもが全く同じ状態で立ち上がります。もし static な IPアドレスを設定していた場合、重複することになりますので、古いホストは停止しておくと良いでしょう。

old_host# shutdown -p now

新しい環境で起動する

新しいホストでは new 環境から起動します。

new_host# bectl activate new
new_host# shutdown -r now

これで新しいマシンで設定も何もかもが同じ FreeBSD が起動します。必要ならば IP アドレスを再設定してください。

host id も同じになりますので、以下のコマンドで host id を再設定すると良いでしょう。

new_host# /etc/rc.d/hostid reset

host id が同じだと bridge(4) や tap(4) に割り当てる MAC アドレスが同じになります。また、NFS のクライアント識別にも使用されており、古いホストと同時に接続するとエラーが表示されます。 zfs のプールにも import 中のシステムの情報として host id が書き込まれます。物理的なディスク装置を抜き出す時は export してからにしましょう。古いホストを再起動する際にはこれらにも注意してください。

Bluetooth keyboard のセットアップ - [loader.conf の設定]

yuichiro@undisclosed.example.com (yuichiro) — Fri, 07 Apr 2023 12:28:29 +0000

Bluetooth keyboard のセットアップ

Bluetooth 経由で keyboard を使用する方法についてまとめます。

loader.conf の設定

USB の Bluetooth ドングルを指すと Bluetooth オーディオ向けにアイソクロナス転送 (isochronous transfer) の割り込みが非常にたくさん発生します。systat -vmstat で xhci の割り込みを確認すると毎秒 1000〜2000 の割り込みが発生している様子を観察することができます。ehci の場合は比較的穏やかなので気にならないでしょう。

Bluetooth オーディオを使わないのであれば、システムに余計な負荷をかけるだけですので、OFF にすることができます。

FreeBSD 13.1 以降であれば、loader.conf に以下の設定を書き、再起動するとアイソクロナス転送を無効にできます。

net.bluetooth.usb_isoc_enable=0

sysctl でも設定できますが、その場合は sysctl で設定後に Bluetooth ドングルを挿してください。既に挿してある場合には一度抜き差しする必要があります。

暗号化の設定

デフォルトの設定では Bluetooth の通信は暗号化されていません。うっかり root のパスワードをキーボードから打ち込み、それが盗聴されていた場合、パスワードの流出に繋がります。

Bluetooth デバイスのデフォルトの設定は /etc/defaults/bluetooth.device.conf にあります。これを使用するデバイス毎に設定を上書きすることができます。

Bluetooth のドングルが ubt0 として認識されている場合、/etc/bluetooth/ubt0.conf を作成して、以下の設定を書き込みます。

authentication_enable="YES"
discoverable="NO"
encryption_mode="P2P"

この例では認証を有効にして、ホストアダプタを検出されないように設定し、データ通信を暗号化します。

もし、Bluetoothドングルが複数ある場合にはその分のファイル (ubt1.conf, ubt2.conf, …) を作成します。

デーモン起動

Bluetooth キーボードを使うために必要なデーモンを起動します。

service bthidd enable
service bthidd start
service hcsecd enable
service hcsecd start

bluetooth-config

Bluetooth のペアリングを簡単に行うためのスクリプトが FreeBSD 12.1 から用意されています。rootで bluetooth-config scan を実行すると、ペアリングモードのデバイスを検索し、対話的に必要な設定を行ってくれます。

以下に動作例を示します。

<予め bluetooth キーボードをペアリングモードにしておく>

# bluetooth-config scan
Scanning for new Bluetooth devices (Attempt 1 of 5) ... done.
Found 2 new bluetooth devices (now scanning for names):
[ 1] b8:f6:b1:00:e7:97  "AppleWirelessKeyboard" ()
[ 2] 28:c1:3c:6e:ce:2f  "AQUOS-4KTVJ17" ()
Select device to pair with [1-2, or 0 to rescan]: <1 を入力>

Adding device b8:f6:b1:00:e7:97 to /etc/bluetooth/hosts.
Enter friendly name. [AppleWirelessKeyboard]:  <リターンキー入力>
Notice: Using sanitized name"AppleWirelessKeyboard" in /etc/bluetooth/hosts.

Writing pairing information description block to /etc/bluetooth/hcsecd.conf.
(To get PIN, put device in pairing mode first.)
Enter PIN [nopin]: <pin 番号入力>
Stopping hcsecd.
Waiting for PIDS: 3027.
Starting hcsecd.

<ここで bluetooth キーボードから pin を入力しリターンキーを押す>

This device provides human interface device services.
Set it up? [yes]: <リターンキー入力>
syntax error in line 1
Writing HID descriptor block to /etc/bluetooth/bthidd.conf ... success.
To re-read its config, bthidd must be restarted.
Warning: If a Bluetooth keyboard is being used, the connectionmight be lost.
It can be manually restarted later with
 service bthidd restart
Restart bthidd now? [yes]: <リターンキー入力>
Stopping bthidd.
Waiting for PIDS: 1813.
Starting bthidd.

もし、エラーが発生した場合は bluetooth-config scan を再度実行する、もしくは bthidd や hcsecd を再起動するなどしてください。機器との相性によってはこれらを複数回行うこともあるかもしれません。

接続確認

Bluetooth ドングルが ubt0 で認識されている場合、以下のコマンドで接続を確認できます。

$ hccontrol -n ubt0hci read_connection_list
Remote BD_ADDR    Handle Type Mode Role Encrypt Pending Queue State
AppleWireless_        71  ACL    2 MAST     P2P       0     0 OPEN

Encrypt が P2P になっていれば、データ通信が暗号化されています。

open-vm-tools の役割 - open-vm-tools の役割を追加した

asou@undisclosed.example.com (asou) — Tue, 27 Dec 2022 07:06:54 +0000

VMware Workstation/Fusion などの VMware 上の仮想マシンに FreeBSD をインストールした場合には、VMware 用の以下のパッケージもインストールしてください。

VMware 環境でマウスカーソルが動かない問題は、これをインストールしていないためです。

$ sudo pkg install xf86-input-vmmouse
$ sudo pkg install xf86-video-vmware
$ sudo pkg install open-vm-tools

VMware Fusion 12.2.4 (20071091) では、上記のインストールのみで動作するようになりましたが、他のバージョンあるいは Player では何らかの設定ファイルに設定の追加・変更などが必要になることがあるかもしれません。

open-vm-tools の役割

上記のパッケージのうち、open-vm-tools はインストールしなくても X Window System は正しく動作します。しかし、open-vm-tools は以下の機能を有しているので、インストールすることをお勧めします。

balloon ドライバ

VMWare のホストは、ゲスト OS がメモリを要求すると確保します。しかし、ホストからはゲストでメモリが不要になったことを知ることができません。balloon ドライバは、不要になったメモリ領域をホストに伝え、ホスト側でメモリを解放できるようにします。

ゲスト OS およびその上で動作するアプリケーションが使用するメモリ量が大幅に増減する場合、不要なメモリがホストに返却されるため、ホストおよび他に動作しているゲスト OS が恩恵を受ける可能性が考えられます。

vmware-user デーモン

vmware-user デーモンは、仮想マシンのイベントをゲスト OSに送ったり、その逆を行うものです。仮想マシンのウィンドウサイズを変更したときに、その解像度をゲスト OS に知らせるイベントが送られます。vmware-user デーモンが上がっていると、解像度を自動的に変更してくれます。

その他の機能もあるようですが、FreeBSD では動作しないようです。

デスクトップ環境の設定 - [VMware の場合] open-vm-tools を追加した

asou@undisclosed.example.com (asou) — Tue, 27 Dec 2022 06:34:45 +0000

デスクトップ環境の設定

本ページでは、下記のようなデスクトップ環境の設定手順を説明します。

X Window System のインストール

FreeBSD でデスクトップ環境を使用するには、X Window System https://www.x.org/wiki/ と Desktop 環境 Xfce https://www.xfce.org/ をインストールしなければなりません。また、上記のログイン画面を表示するためには、XDM (X Display Manager) もインストールしなければなりません。

Xorg のインストール手順は、https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x-install.html に記載されています。
Desktop 環境のインストール手順は、Handbook https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x11-wm.html に記載されています。
本ページでは Xfce のインストール手順を記述していますが、上記のハンドブックには GNOME/KDE のインストール手順も記載されています。
XDM のインストール手順は、Handbook https://docs.freebsd.org/en/books/handbook/x11/#x-xdm に記載されています。

パッケージのインストール

FreeBSD のインストール時に作成したユーザー (例では yamada) でログインしてから、pkg コマンドを使用して Xorg, Xfce, 日本語フォントのパッケージをインストールします。

パッケージのインストールには sudo コマンドを使用することを前提にしています。
sudo コマンドをインストールしていない場合には、su コマンドでスーパーユーザーになって「pkg install sudo」でインストールします。
- sudo コマンドを使用せずに、スーパーユーザーになって以下のコマンドを (sudo なしで) 実行しても構いません。

$ sudo pkg install xorg
$ sudo pkg install xfce
$ sudo pkg install japanese/font-std

japanese/font-std をインストールしなくても日本語の表示は可能ですが、その際に使用されるフォントはあまり美しくないので、japanese/font-std をインストールすることをお勧めします。

日本語入力のために Fcitx https://fcitx-im.org/wiki/Fcitx もインストールします。

$ sudo pkg install ja-fcitx-mozc

Web browser は Firefox をインストールします。

$ sudo pkg install firefox

VMware の場合

VMware Workstation/Fusion などの VMware 上の仮想マシンに FreeBSD をインストールした場合には、VMware 用の以下のパッケージもインストールしてください。

VMware 環境でマウスカーソルが動かない問題は、これをインストールしていないためです。

$ sudo pkg install xf86-input-vmmouse
$ sudo pkg install xf86-video-vmware
$ sudo pkg install open-vm-tools

システムの設定

Xfce4 はメッセージパスに D-Bus を使用するので、以下の手順で D-Bus を有効にしてデーモン (daemon, サービス) を起動します。

$ sudo sysrc dbus_enable="YES"
$ sudo service dbus start

設定ファイルの作成

vi/emacs などのテキストエディターを使用して、.xinitrc というファイルに以下の内容を書き込んでください。

.xinitrc ファイルは、ホームディレクトリにおいてください。
日本語キーボードを使用している場合には、「#/usr/local/bin/setxkbmap -layout jp」の行頭の「#」を削除してください。

export LC_ALL=ja_JP.UTF-8
export LANGUAGE=ja_JP.UTF-8
export LANG=ja_JP.UTF-8
#
export GTK_IM_MODULE=fcitx
export QT_IM_MODULE=xim
export XMODIFIERS=@im=fcitx
/usr/local/bin/mozc start
/usr/local/bin/fcitx -r -d
#
#/usr/local/bin/setxkbmap -layout jp
#
exec /usr/local/bin/xfce4-session

X Window system の起動

コンソールからログインして、startx コマンドを実行します。

$ startx

左上の「アプリケーション」をクリックして「ウェブブラウザー」をクリックすると、Firefox が起動します。

キーボードの「Ctrl + SPACE」を押すと日本語の入力ができます。

左上の「アプリケーション」をクリックして「ログアウト」をクリックすると「Taro Yamada のログアウト」というダイアログが表示されるので、「ログアウト」をクリックすると X Window System が終了します。

XDM の設定

ここまでの説明では、下記のような文字列ベースのログイン画面からログインし、startx コマンドを使用してデスクトップ環境を手順を説明しました。

ログイン時から下記のようなグラフィカルベースのログイン画面からログインしてデスクトップ環境を使用するには、XDM (X Display Manager) をインストールしなければなりません。

XDM をインストールする前に、上記の「設定ファイルの作成」で作成した .xinitrc ファイルの名称を変更しておきます。

$ mv .xinitrc .xsession

startx コマンドを使用した場合には .xinitrc ファイルが参照されます。
XDM からログインした場合には、.xsession ファイルが参照されます。

pkg コマンドを使用して XDM をインストールします。

$ sudo pkg install xdm

XDM をインストールしたならば、以下のコマンドを実行して XDM を有効にします。

$ sudo sysrc xdm_enable="YES"
$ sudo service xdm start

service xdm start コマンドを実行すると、コンソールに上記の画面が表示されます。

Login: username + Enter キー
Password: password + Enter キー

を入力すると (password の入力中は何も表示されません)、

下記のデスクトップ画面が表示されます。

ZFS Tips - [atime は off に]

yuichiro@undisclosed.example.com (yuichiro) — Tue, 13 Sep 2022 02:33:13 +0000

ZFS Tips

ZFS を運用するにあたってのチップスです。

atime は off に

UNIX の伝統的なファイルシステムには atime というアクセスされた時刻を保持するフィールドがあります。 ZFS もこの機能をサポートしておりデフォルトでは on に設定されています。しかし、Copy On Write を基本とする ZFS と atime は非常に相性が悪く、性能劣化を引き起こす要因になります。なぜならば読み込み操作を行うたびに atime の更新という書き込み処理が発生し、全ての書き込みは Copy On Write で一度コピーが作成されるため、読み込み操作の数に比例して作業用にディスク容量を必要とすることになります。性能面、資源面ともにデメリットとなりますので、off にしましょう。

なお、FreeBSD のインストーラから ZFS root でインストールした場合、インストーラが zroot の atime を off にします。そのため、後から自分で追加したプールに対して設定が必要となります。

ただし、 zroot/var/mail だけは atime on に設定されます。tcsh などがメールの到着をチェックするためです。

プールには必ず空き容量を確保すること

ZFS は Copy On Write が基本です。ファイルを削除する場合でもメタデータやディレクトリの書き換えが発生する分、コピーが発生します。このときコピーできるだけの容量がプールになければファイルを削除することができません。もし、プールを 100% 使い切ってしまうと、それはリードオンリーになることと同じ意味を持ちます。そうなる前に不要なスナップショットやファイルを削除するようにしましょう。もし不幸にも使用率が100%になってしまったら、プールにディスクを追加して容量を増やすか、より大きなプールに全データを移すしかありません。

経験的にはプールの使用率が 70〜80% をキープするくらいが安全と思われます。もし、性能を厳しく追い求めるならば使用率を 50% くらいまでにすると空き領域の検索が速い分、高速に動作する可能性が高いです。

ハードディスクのパーティション

プールに追加するハードディスクはパーティションを切っておいたほうが良いです。

パーティションがないほうが性能面では有利になりますが、その差はわずかです。長年運用を続けたあとにハードディスクを故障で交換する際にセクタ数まで含めて同じハードディスクを入手できるかどうかは分かりません。おそらくより大容量のモデルを購入することになるでしょう。その場合、予めパーティションを作成しておけば、同じサイズにパーティションを切り直すだけで、交換ディスクとして使用することができます。余ったパーティションを他の用途に使うこともできます。ディスク障害から復旧したら後日、プールサイズの拡張などを検討すればよいのです。

ARC の使用量を知る

ZFSのプールがあれば top(1) が ARC のサマリを表示します。以下に表示のサンプルを示します。

ARC: 2864M Total, 884M MFU, 1793M MRU, 1696K Anon, 34M Header, 150M Other
     2065M Compressed, 4466M Uncompressed, 2.16:1 Ratio

それぞれの項目の意味は次の通りです。

項目	内容
Total	ARC全体のデータ量
MFU	最もよく使われるデータとして保持している量
MRU	最も間近に使われたデータとして保持している量
Anon	一時的なデータとして保持している量
Header	ヘッダのデータ量
Other	その他のデータとして保持している量
Compressed	圧縮した状態で保持しているデータ量
Uncompressed	圧縮前のデータ量
Ratio	圧縮率

ARC サイズの制限

デフォルトでは搭載メモリ量 - 1GB が ARC の最大値として割り当てられます。つまり 8GB のメモリを搭載した環境では 7GB まで ARC に使われる可能性があります。

これを制限するパラメータが sysctl の vfs.zfs.arc.max ¹⁾です。アプリケーションにどの程度メモリを空けて置きたいのかを考えて、ARC を制限しましょう。

例えば 4GB に制限するには以下のようにします。

sysctl vfs.zfs.arc.max=4294967296

L2ARC のメモリ使用量

L2ARC は割り当てた容量の約 1.59% のメモリをその管理に使用します。つまりキャッシュヒット率をあげようとして 1TB の SSD を割り当てたとすると

1 TB * 0.0159 = 15.9 GB

で約16GBのメモリを使用します。

メインメモリがこのサイズ以下の環境では満足な性能を得られないでしょう。

逆に L2ARC の管理に 1GB のメモリを割り当てると考えると、逆算して 63GB の L2ARC を割り当てるべきということが分かります。

1 GB / 0.0159 = 62.89 GB

L2ARC はコールドブート

FreeBSD 12.0 現在、 L2ARC の内容は電源を落とすと失われます。（将来的には改善される見込みです）

厳密には L2ARC のメディアに乗っている内容は保持されますが、メモリ上の管理データを失いますので、その内容を再利用してくれません。

リブート直後は L2ARC は全てミスヒットすることを覚えておいてください。必要ならばアプリケーションレベルでウォームアップを行ってください。

ユーザマウント

zfs では特定のユーザに対し、一部のファイルシステム操作を許可する設定ができます。これを利用すると、例えばユーザのホームディレクトリの下に限って、zfs ファイルシステムの作成、マウント、スナップショットの作成、クローンの作成などを許可することができます。許可の設定自体は root 権限が必要ですが、一度許可を与えてしまえば限られた範囲の操作はユーザ権限で行うことができます。

例えば、 `zpool/home/alice` にユーザ alice のホームディレクトリがあった場合、 alice に対して以下の操作を許可するようにします。

# zfs allow alice create,destroy,mount,clone,promote,rename,snapshot,rollback zpool/home/alice

権限の意味はそれぞれ zfs のサブコマンドに対応しています。上記の例ではファイルシステムの作成、破棄、マウント、クローン、クローン元への依存を削除、リネーム、スナップショット作成、ロールバック、を alice に対して許可しています。

これでユーザ alice は自身のホームディレクトリの下であれば、自由に zfs のファイルシステムを作成・破棄することができます。

なお、FreeBSD ではユーザ権限でマウントを許可する際には `sysctl vfs.usermount=1` が必要です。

/etc/sysctl.conf に `vfs.usermount=1` を書くのを忘れないようにしましょう。

`vfs.usermount=1` を設定すると zfs だけでなく、 CD/DVD などのマウントや fuse によるマウントも権限があれば実行できるようになります。

send & recv のレジューム

zfs のバックアップにスナップショットを send & recv するのは定番とも言えますが、ファイルシステムの使用量が大きくなるとバックアップに時間がかかるようになります。ひょっとするとネットワークの不調などで途中で止まってしまうことがあるかもしれません。その場合、最初からやり直すのはとても辛いため、途中からやり直すことができます。

zfs recv に -s オプションを渡すと recv が途中で止まった際にどこで止まったのかを示すトークンを保存してくれます。トークンは recv したファイルシステムの receive_resume_token プロパティに保存されます。このトークンを zfs send の -t オプションに渡すと、途中から再開してくれます。

以下にユーザ alice のホームディレクトリをバックアップする際の簡単な例を示します。

# zfs send zpool/home/alice | zfs recv -s zpool/backup/alice
# ^C (一時停止)
# zfs get -H -o value receive_resume_token zpool/backup/alice
1-d2524e736-d0-789c636064000310a500c4ec50360710e72765a526973030f0419460caa7a515a79680647679c0e4d990e4932a4b528b81b44640743536fd25f9e9a599290c0c193176fb8c54d81e3a20c97382e5f31273531918aa0af2f373f433f27353f52b4b339333328bf2f5cbf38bb21d8c0c0c2d740d0c758dcc196000003b291e6b
# zfs send -t '1-d2524e736-d0-789c636064000310a500c4ec50360710e72765a526973030f0419460caa7a515a79680647679c0e4d990e4932a4b528b81b44640743536fd25f9e9a599290c0c193176fb8c54d81e3a20c97382e5f31273531918aa0af2f373f433f27353f52b4b339333328bf2f5cbf38bb21d8c0c0c2d740d0c758dcc196000003b291e6b' | zfs recv -s zpool/backup/alice

２回目以降の zfs send にはトークンのみを渡して、ファイルシステム名は渡しません。 zfs recv の受け側は必要に応じて ssh や nc などを利用するとネットワーク経由でバックアップすることができます。

dedup は安易に使わないこと

dedup はファイルの中の重複箇所を自動的に検出し、zfsのブロック単位でまとめてくれる便利な機能ですが、反面ハッシュ値の保持や比較に多くのリソースを使用します。 dedup では1つのハッシュを保持するのに320bytesを消費するため、例えば1ブロック128kbで2TBのデータを保持したとすると5GBのメモリを使用します。

2,147,483,648 KB / 128 = 16,777,216 blocks
320 * 16,777,216 = 5,368,709,120 bytes = 5GB

もちろん、この値はARCとは無関係です。そして全ての書き込みでハッシュ値との比較処理が走ります。資源面、性能面ともに多くのリソースを必要としますので、通常は使わないほうが良いです。また、dedup を有効にした後に書き込まれたファイルは常に dedup 用のハッシュ値を保持するようになります。 dedupを無効にしてもその後に書かれたファイルに対してハッシュ値の比較が行われなくなるだけで既に書き込まれたファイルは dedup の対象となります。完全に無効化するにはファイルを再度コピーする必要があります。

もちろん、上記のリソースを確保した上で dedup を使用することには何の問題もありません。

swap ボリュームについて

zfs ではプールからブロックデバイスを生成する機能があるため、これを swap として利用することができます。しかし、swap はメモリが逼迫したときに使用されるものですので、そもそも大量にメモリを使う zfs で swap を賄うのは矛盾した状態を生み出します。

例えば、zfs の ARC が増大しアプリケーションが使えるメモリが少なくなったために swap を使用するような場合、swap に書き込みが行われることで更に ARC を使用しますます使えるメモリが減ることにつながります。

swap を zfs 上に取るのは便利ではありますが、あまり得策とは言えません。

PostgreSQL

atime

atime は off にしましょう。理由は前述の通りです。

record size

PostgreSQL のデータ領域に ZFS を使う場合、record size を 8k にしましょう。デフォルトでは 128k です。

例として zroot/postgres に対して record size を 8k にするには以下を実行します。

zfs set recordsize=8k zroot/postgres

ZFS は record size 毎にまとめてディスクアクセスを行います。 PostgreSQL は 8k 単位でディスクアクセスを行いますので、 PostgreSQL が 8k を書き込もうとしたときには ZFS は 128k サイズを読み込んだ上で 8k を変更し、それを 128k 単位で書き込もうとすることになり、効率が悪くなるのです。

log bias

log bias を throughput にすると、ZFS は書き込みデータをログデバイスに書き込むことをやめます。PostgreSQL には WAL がありますので、ZFS がログを書き込む意味はないと言っても良いでしょう。無駄な書き込みがなくなる分、性能向上が期待できます。

zfs set logbias=throughput zroot/postgres

primary cache

PostgreSQL はアプリケーション側で必要なデータをメモリ内にキャッシュしますので、 ZFS 側でデータをキャッシュする意味は少なくなります。もし、ARC のサイズを小さくしたいならば、メタデータのみキャッシュするように変更することができます。

zfs set primarycache=metadata zroot/postgres

これにより性能向上が得られるかどうかはケースバイケースです。 PostgreSQL 側のバッファサイズなどと合わせて全体をチューニングした上で判断してください。

compression

lz4 による圧縮は非常に高速に動作します。圧縮率はそれほど良くはありませんが、半分程度に圧縮されれば、見た目のスループットは2倍に向上します。圧縮率が悪くても lz4 が高速に動作するためペナルティが少なく、設定するメリットは十分にあります。

zfs set compression=lz4 zroot/postgres

MySQL (innodb)

atime

atime は off にしましょう。理由は前述の通りです。

record size

データ用とログ用に2つのファイルシステムを用意します。データ用には recordsize=16k を、ログ用はデフォルトの recordsize=128k を設定します。

用途	recordsize
データ用	16k
ログ用	128k (default)

innodb はデータの読み書きを一度に 16k ずつ行うため、それに合わせます。ログ用は追記のためデフォルトのままでかまいません。

log bias

innodb でもログを先行書き込みしますので zfs でログを書き込む必要はないとも言って良いでしょう。データ用のファイルシステムに対し logbias=throuput を設定し zfs のログの書き込みを OFF にします。ログ用については失われると困るため、デフォルトのまま logbias=latency が良いでしょう。

用途	logbias
データ用	throuput
ログ用	latency (default)

primary cache

MySQL もアプリケーション側で必要なデータをメモリ内にキャッシュします。こちらを十分に効かせれば ZFS でキャッシュさせる必要性は低くなりますので、 primarycache=metadata を設定し、メタデータのキャッシュのみを行うようにします。

データ用、ログ用、どちらにも言えます。

用途	primarycache
データ用	metadata
ログ用	metadata

compression

データ用、ログ用ともに compression=lz4 を設定しておくと良いでしょう。

用途	compression
データ用	lz4
ログ用	lz4

skip_innodb_doublewrite

my.cnf に skip_innodb_doublewrite を設定し MySQL にデータを2回書く処理を止めさせます。

これはもともと 16k のデータの内、半分の 8k だけはディスクに書かれたが残りの 8k は書かれていないようなタイミングで電源喪失などが発生した際にそれを検知するためのものです。 Copy On Write の ZFS ではどのようなタイミングでもこういう事にはならないため、単純に OFF にすることができます。 2回の書き込みが1回に減る分、性能向上が期待できます。

MySQL (MyISAM)

atime

atime は off にしましょう。理由は前述の通りです。

record size

MyISAM は一度に 8k ずつデータを読み書きしますので、recordsize=8k を指定します。ログ用にディレクトリを分けることができませんので、データ用に合わせます。

primary cache

MyISAM でもアプリケーション側で必要なデータをメモリ内にキャッシュします。 primarycache=metadata で zfs の arc 使用量を制限し、アプリケーション側で使えるメモリを増やします。

log bias

データとログが同じファイルシステムに置かれるため、安全のためデフォルトのまま logbias=latecy にするのが良いでしょう。

compression

lz4 で得られるメリットは innodb と同じです。

¹⁾

13.0-RELEASE より前は vfs.zfs.arc_max でした