Share FreeBSD based information - os

10Gbps のパケット転送

anonymous@undisclosed.example.com (Anonymous) — Thu, 02 Nov 2023 10:25:02 +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 を設定します。

Boot Environment

anonymous@undisclosed.example.com (Anonymous) — Mon, 27 Dec 2021 01:35:02 +0000

Boot Environment

Boot Environment とは ZFS をルートファイルシステムに選んだ場合に使える機能です。ルートファイルシステムのクローンを任意に作成し、どのクローンから起動するのかを自由に切り替えることができます。

例えば、新しいリリースまたはパッチを試すために、現在の環境のクローンを作成しバックアップ用に取っておきます。

その上で、新しいリリースまたはパッチをインストールして、うまくいけばそのまま使い続ければ良いですし、何か問題が発生したならば、バックアップ用に取っておいた環境からブートすれば、元に戻ります。

また、異なるバージョンの FreeBSD をインストールしておき、切り替えて使うこともできます。

セットアップ

FreeBSD のインストーラでルートファイルシステムに zfs を選んでインストールします。すると次のような zfs のファイルシステム構成になります。

$ zfs list
NAME                 USED  AVAIL  REFER  MOUNTPOINT
zroot                683M  12.4G   176K  /zroot
zroot/ROOT           680M  12.4G   176K  none
zroot/ROOT/default   679M  12.4G   679M  /
zroot/tmp            176K  12.4G   176K  /tmp
zroot/usr            704K  12.4G   176K  /usr
zroot/usr/home       176K  12.4G   176K  /usr/home
zroot/usr/ports      176K  12.4G   176K  /usr/ports
zroot/usr/src        176K  12.4G   176K  /usr/src
zroot/var           1.09M  12.4G   176K  /var
zroot/var/audit      176K  12.4G   176K  /var/audit
zroot/var/crash      176K  12.4G   176K  /var/crash
zroot/var/log        232K  12.4G   232K  /var/log
zroot/var/mail       176K  12.4G   176K  /var/mail
zroot/var/tmp        176K  12.4G   176K  /var/tmp

この zroot/ROOT/default がデフォルトのルートファイルシステムです。ルートファイルシステムに含まれるディレクトリは /dev を除いた / 以下の全てのディレクトリです。 /usr や /var も含みます。

逆を言うと個別にマウントされたものがルートファイルシステムには含まれないことになります。上記のリストでは以下が該当します。

/tmp
/usr/home
/usr/ports
/usr/src
/var/audit
/var/crash
/var/log
/var/mail
/var/tmp

zroot/usr と zroot/var はルートファイルシステムに含まれない領域を作り出すためのダミーです。マウントポイントが割り当てられていますが、mounted が no のため実際にはマウントされていません。

$ zfs get mounted,canmount zroot/usr zroot/var
NAME       PROPERTY  VALUE     SOURCE
zroot/usr  mounted   no        -
zroot/usr  canmount  off       local
zroot/var  mounted   no        -
zroot/var  canmount  off       local

mount コマンドでも確認することができます。

$ mount
zroot/ROOT/default on / (zfs, local, noatime, nfsv4acls)
devfs on /dev (devfs, local, multilabel)
zroot/tmp on /tmp (zfs, local, noatime, nosuid, nfsv4acls)
zroot/usr/home on /usr/home (zfs, local, noatime, nfsv4acls)
zroot/usr/ports on /usr/ports (zfs, local, noatime, nosuid, nfsv4acls)
zroot/usr/src on /usr/src (zfs, local, noatime, nfsv4acls)
zroot/var/audit on /var/audit (zfs, local, noatime, noexec, nosuid, nfsv4acls)
zroot/var/crash on /var/crash (zfs, local, noatime, noexec, nosuid, nfsv4acls)
zroot/var/log on /var/log (zfs, local, noatime, noexec, nosuid, nfsv4acls)
zroot/var/mail on /var/mail (zfs, local, nfsv4acls)
zroot/var/tmp on /var/tmp (zfs, local, noatime, nosuid, nfsv4acls)
zroot on /zroot (zfs, local, noatime, nfsv4acls)

管理ツール

Boot Environment を扱うためのツールとして以下の２つがあります。

bectl
- FreeBSD 12.0 から標準搭載されたコマンドラインツールです。
beadm
- ports/pkg でインストールできるコマンドラインツールです。
  bectl がない環境でも使うことができます。

どちらも機能的にはほとんど変わりません。このページでは bectl を例に説明します。

使い方

1. ルートファイルシステムをクローンする

bectl create <環境名>

現在のルートファイルシステムのスナップショットを取り、そこから新しいルートファイルシステムを作成します。

zroot/ROOT/<環境名> というファイルシステムが作成されます。

既にルートファイルシステムにスナップショットがあるならば、そこからクローンすることもできます。

bectl create -e <環境名>@<スナップショット> <環境名>

例えば default@2019-04-01 から test というルートファイルシステムを作成するのは次のようになります。

bectl create -e default@2019-04-01 test

2. 次回起動時のルートファイルシステムを変更する

bectl activate <環境名>

次回起動時のルートファイルシステムを <環境名> に変更します。

3. ルートファイルシステムの一覧表示

bectl list

作成したルートファイルシステム一覧を表示します。結果は次のように表示されます。

BE          Active Mountpoint Space Created
default     NR     /          248K  2019-06-12 18:45
test               -          679M  2019-06-12 18:53

この例では default と test の２つのルートファイルシステムがあります。

N,R の意味は次の通りです。

N: 現在アクティブなファイルシステムです。 (Now Active)
R: 次回起動時に選ばれるファイルシステムです。 (Reboot next time)

4. ルートファイルシステムの削除

bectl destroy <環境名>

作成したルートファイルシステムを削除します。

5. ルートファイルシステムのマウント

bectl mount <環境名> <マウントポイント>

指定したルートファイルシステムをマウントします。マウントポイントを省略した場合は /tmp にテンポラリのマウントポイントを作成し、そこにマウントします。

アンマウントするには以下を実行します。

bectl umount <環境名>

6. 環境名の変更

bectl rename <古い環境名> <新しい環境名>

環境の名前を変更します。これは現在起動している環境に対して行うことも可能です。

7. jail 起動

bectl のみの機能です。

bectl jail <環境名>

ルートファイルシステムから jail を作成し、その中で動く sh を起動します。ネットワーク環境はセットアップされません。sh から手動で設定します。

ブートローダでの選択

もし、新しいルートファイルシステムにトラブルがあり、カーネルすら起動できなくなった場合はブートローダでルートファイルシステムを選択することができます。

起動直後の画面で "7" を押します。

"2" を押すと、ブートする環境が切り替わります。

元の環境を選びスペースキーを押すと、その環境でブートします。

起動したらアクティブなファイルシステムを切り替えましょう。

bectl activate default

ローダはアクティブなファイルシステムを切り替えてはくれません。

ユースケース

実際に freebsd-update を行う場合を例にとると一連の操作の流れは次のようになります。

1. バックアップの作成

bectl create backup

"backup" という名前で新しいルートファイルシステムを作成します。

2. freebsd-update

freebsd-update fetch install

freebsd-update を実行しシステムを更新します。

3. 再起動

shutdown -r now

アップデート後に再起動します。

4. 動作確認

ps でプロセスを確認するなど、動作を確認します。

5. 切り戻し

もし、4. の動作確認で問題があれば、"backup" をアクティベートし、再起動します。

bectl activate backup
shutdown -r now

その後、default を削除し、backup を default にリネームすると元に戻ります。

bectl destroy default
bectl rename backup default

6. 古いバックアップの削除

bectl destroy backup

ある程度安定的に動くことが分かったならば、不要になったバックアップを削除します。

DC-TCP

anonymous@undisclosed.example.com (Anonymous) — Thu, 09 May 2019 08:35:39 +0000

DC-TCP

FreeBSD 11.0以降、TCPのCongestion Control機構としてDC-TCPが利用できる。これを利用する設定を以下に記載する。

なお、Install時の標準は、NewReno。(@2019/050/09現在)

手動での切り替え
- 以下を実行する
```
# kldload cc_dctcp
# sysctl -w net.inet.tcp.cc.algorithm=dctcp
# sysctl -w net.inet.tcp.ecn.enable=1
```
- ECNの確認(1 or 2であること)
```
# sysctl net.inet.tcp.ecn.enable
1
```
  - 0: ECNを利用しない
  - 1: ECNを利用。送受信
  - 2: ECNを利用。受診時のみ

永続化

/boot/loader.conf
```
cc_dctcp_load="YES"
```

/etc/sysctl.conf

net.inet.tcp.cc.algorithm=dctcp
net.inet.tcp.ecn.enable=1

/etc ディレクトリにあるファイルの用途

anonymous@undisclosed.example.com (Anonymous) — Tue, 28 Jan 2020 09:31:53 +0000

/etc ディレクトリにあるファイルの用途

x11/

xorg の設定を入れるディレクトリです。

aliases

mail/aliases へのシンボリックリンクです。メールアドレスのエイリアスを記載します。これを編集した後には newaliases(1) コマンドを実行して設定を反映します。

authpf/

auto_master

autofs/

blacklistd.conf

blacklistd(8) の設定ファイルです。

bluetooth/

bluetooth の設定をまとめたディレクトリです。

cron.d/

cron(8) の設定をまとめたディレクトリです。 crontab と同じ形式のファイルをこの中に作成します。

crontab

cron(8) の設定ファイルです。いつどのコマンドを起動するのかを記載します。

csh.cshrc

システム全体の .cshrc です。 cshを使用する全てのユーザの初期設定を記載します。

csh.login

システム全体の .login です。 cshでログインする全てのユーザで実行されます。

csh.logout

システム全体の .logout です。 cshを使用する全てのユーザのログアウト時の処理を記載します。

ddb.conf

defaults/

設定ファイルのデフォルト値をまとめたディレクトリです。この中のファイルを編集するべきではありません。

devd/

devd.conf

devd(8) の設定ファイルです。

devfs.conf

devfs(5) の設定ファイルです。

dhclient.conf

dhclient(8) の設定ファイルです。

disktab

dma/

dumpdates

fbtab

freebsd-update.conf

freebsd-udpate(8) の設定ファイルです。

fstab

マウントするディスクを記載したファイルです。 zfs はファイルシステムのプロパティにマウントポイントを持つため、このファイルには記載しません。

ftpusers

ftpd(8) でログインを許可しないユーザを列挙するファイルです。

gettytab

group

group id の定義を設定するファイルです。

gss/

host.conf

名前解決の手段を記載したファイルです。 nssswitch.conf から自動生成されますので、編集してはいけません。

hostid

ホスト毎にユニークなidです。もし存在しなければ /etc/rc.d/hostid により生成されます。

hosts

IPアドレスとホスト名の対応表です。

hosts.allow

サービスに対するホストからのアクセス権限を指定します。 hosts_access(3) を使用しているサービスに対して有効です。

hosts.equiv

YP/NIS で信頼するホストやユーザを記載するファイルです。

hosts.lpd

inetd.conf

inetd(8) の設定ファイルです。

libalias.conf

libmap.conf

共有ライブラリのマッピングを変更します。ダイナミックリンカ (ld-elf.so.1) の設定ファイルです。

localtime

システムのタイムゾーンファイルです。 /usr/share/zoneinfo から適切なタイムゾーンのファイルをコピーします。

locate.rc

login.access

login.conf

ログインクラス(login_class(3)) を定義するファイルです。

login.conf.db

mac.conf

mail/

sendmail(8) の設定をまとめたディレクトリです。

mail.rc

make.conf

ベースシステムや ports のコンパイル時に指定するオプションを記載するファイルです。

master.passwd

ユーザ情報が書かれたファイルです。ユーザ名などの他にハッシュ化されたパスワードが書かれていますので、 root以外は読み書きできないようになっています。

motd.template

ログイン時に表示するグリーティングメッセージの元となるファイルです。グリーティングメッセージを変更するときにはこのファイルを編集します。

mtree/

netconfig

netstart

network.subr

networks

newsyslog.conf

newsyslog(8)の設定ファイルです。

newsyslog.conf.d/

newsyslog(8)の設定ファイルをまとめたディレクトリです。

nscd.conf

nscd(8)の設定ファイルです。

nsmb.conf

nsswitch.conf

hosts, passwd, services などのシステム管理上のファイルをどの手段(file, NIS, DNS, LDAP)で解決するのかを指定するファイルです。

ntp/

ntpd(8) の設定をまとめたディレクトリです。

ntp.conf

ntpd(8) の設定ファイルです。

opieaccess

opiekeys

os-release

OSのリリース情報が書かれたファイルです。 13.0 以降で作成されます。

pam.d/

認証モジュールの設定をまとめたディレクトリです。

passwd

ユーザ情報をまとめたファイルです。 master.passwd からハッシュ化パスワードなどの機密情報を抜き、全てのユーザに公開できるようにしたファイルです。

pccard_ether

periodic/

pf.os

phones

pkg/

pkg(8) の設定をまとめたディレクトリです。

portsnap.conf

portsnap(8) の設定ファイルです。

ppp/

printcap

プリンタの設定ファイルです。

profile

sh(1) 用のシステムワイドな設定を記載するファイルです。

protocols

pwd.db

passwd ファイルをデータベース化したものです。

rc

マルチユーザで起動されたときに最初に実行されるファイルです。 rc.d のスクリプトを呼び出します。システム起動に重要なファイルのため編集してはいけません。

rc.bsdextended

rc.conf

FreeBSD起動時の設定を記載するファイルです。設定を変更するには以下の方法があります。

このファイルを直接編集する
sysrc(1) コマンドを使用する
service(8)コマンドを使用する(12.0以降)

記載できる内容は /etc/defaults/rc.conf を見てください。また、/usr/local/etc/rc.d の中にあるファイルのコメントに書かれていることもあります。

rc.conf.d/

rc.conf のうちサービス毎の内容を分割して記載したファイルをまとめたディレクトリです。この中にはサービス名をファイル名としたファイルを生成し、その中に設定ファイルを記載します。

例えば、firewall の設定を分離するには /etc/rc.conf.d/firewall を作成し、その中にfirewallの設定を記載します。

firewall_enable="YES"
firewall_type="OPEN"

rc.d/

ベースシステムが持つサービスの起動スクリプトがまとめられているディレクトリです。この中のファイルを編集してはいけません。

rc.firewall

起動時に firewall を設定する際に実行されるファイルです。ベースシステムで提供されるルールを実装したものです。より高度なルールを設定したいならば、このファイルを編集するのではなく、独自にルールを定義したファイルを作成し、rc.conf のfirewall_scriptで呼び出すとよいでしょう。

rc.initdiskless

ディスクレス起動時に実行されるファイルです。

rc.resume

システムがレジュームした時に実行されるファイルです。

rc.sendmail

sendmail(8) 起動時に実行するファイルです。

rc.shutdown

システムが停止(shutdown)するときに実行されるファイルです。停止時に動かしたいコマンドがあれば、このファイルに追記します。

rc.subr

rc スクリプトが共通に使用するサブルーチンを定義したファイルです。システム上重要なファイルのため編集してはいけません。

rc.suspend

システムがサスペンドするときに実行されるファイルです。

regdomain.xml

remote

resolv.conf

DNSクライアントの設定ファイルです。このファイルを直接編集せずに resolvconf(8) を使用してください。

rmt@

rpc

security/

services

shells

ログインシェルとして使用可能な実行ファイルを列挙します。ここに書かれていないシェルを使用するユーザはログインできません。

snmpd.config

spwd.db

master.passwd ファイルをデータベース化したものです。

src.conf

ベースシステムのコンパイル時に渡すオプションを記載します。どのような値が設定できるのかは src.conf(5) を参照してください。

ssh/

ssh/sshd の設定をまとめたディレクトリです。

ssl/

openssl の設定をまとめたディレクトリです。

sysctl.conf

システム起動時に設定するsysctl の値を記載します。チューニングパラメータなどを書きます。

syslog.conf

syslogd(8) の設定ファイルです。どのログをどこに出力するのかを記載します。

syslog.d/

termcap

/usr/share/misc/termcap へのシンボリックリンクです。 temcap データベースファイルです。

termcap.small

termcap のサブセットです。

ttys

unbound@

wall_cmos_clock

このファイルがある場合、CMOSクロックはローカルタイムを保持していると解釈します。 Windows とのデュアルブート時には設定する必要があります。

zfs/

FreeBSD マシンの引っ越し

anonymous@undisclosed.example.com (Anonymous) — Wed, 09 Aug 2023 01:05:02 +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 してからにしましょう。古いホストを再起動する際にはこれらにも注意してください。

FreeBSDにおけるFIB

anonymous@undisclosed.example.com (Anonymous) — Sat, 01 Jun 2019 03:13:48 +0000

FreeBSDにおけるFIB

FreeBSDでは、FIB(Forwarding Informations Base)を複数持つことができる。

FIBとは

以下、経路表(以下RI)とFIBの違いを不正確を承知で簡単にまとめておく

特に動的経路制御(RIP/OSPF/BGP/IS-ISなど)を行っているような場合、同一destinationへのnexthopが複数個RIに登録されることがある。
しかし、Kernelは、パケットを送出するときに「どこに投げれば良いか」を、毎回Riを参照して、いちいち再計算して送り出すのは効率が悪い
RIが書き換わったときに、再計算して、destination単位でnexthopを決め、再計算不要な表を事前に作っておけば便利
この送出時の再計算を不要にするための表がFIB

このFIBが複数あるということで、例えばJail環境におけるPrisoner毎に利用するFIBを変えたり、pfなどを利用してPolicy Routingを行ったりすることが容易になる（と思われる）。

net.fibs

FreeBSDにおいて、sysctl net.fibsを実行すると、現在のFreeBSD kernel内のFIB数がわかる。

FIBには0から順番に番号が付与されている。また、 FIBはプロセス単位で割り当てることが可能である。 FreeBSD 7.1-RELEASE以降、特に設定しなければ、FIBは1個で、FIB 0が利用される。

setfib(1)を利用することでプロセスにFIBを割り当てることができる。

# setfib -1 ping www.example.com

この場合、ping には FIB 1が割り当てられる。

コマンドによってはFIBを指定するオプションが用意されている。たとえばrouteコマンドは次のようにして、経路情報の変更をどのFIBに反映させるかを指定できる。

route add -net -inet 192.168.2.0/24 10.0.0.1 -fib 2

netstat -rの場合は、次のように指定する。

netstat -r -F 2

FIBを複数用意して、"netstat -nrF 1" のように実行してみると、感じがつかめる筈。

FIBが複数ある場合の利用FIBの決定アルゴリズムは以下の通り。

FIBが設定されているパケットは、設定されているFIBが使われる。設定されていなければ、FIB 0が使われる
外部から到着して、IP forwardingの対象となるパケットには、FIB 0が使われる
あるプロセスがlistenしているTCPソケットがあり、そのプロセスにFIBが割り当てられている場合、acceptしたソケット側にも同じFIBに割り当てられる
TCP以外でFIBが割り当てられているパケットの場合、そのパケットに対する応答パケットは、同じFIBが割り当てられる
gif(4)やtun(4)などのトンネルインタフェースで生成されるカプセル化されたパケットは、そのインタフェースを作ったプロセスのFIBが割り当てられる
- ifconfig gif0 create tunnelfib 1 とした場合、gif0でカプセル化されたパケットはFIB 1で処理される
- ifconfig gif0 create fib 1 とした場合、受信してgif0でカプセル化解除されたパケットがFIB 1で処理される
ルーティングメッセージは、そのメッセージを生成したプロセスのFIBが割り当てられる

上記決定ロジックによってFIBが決定されるので、FIB 1に適当に経路を追加・削除しても、FIB 0を修正しない限り影響はない(筈)。

FIB数は、カーネルオプションの他、loader tunableでも変更可能。(/etc/sysctl.confでは変更不能)。以下主要なtunables.

net.fibs: FIB数。16個まで指定可能。
net.my_fibnum: デフォルト FIB の番号
- 何も指定しなければ0になる。
net.add_addr_allfibs: デフォルトFIB以外の全FIBに、インタフェースの経路を自動的に追加するかどうか。
- defaultは1
- 0にすると、明示的に経路を追加しない限り0番以外には経路が追加されない

なお、FIBはIPFWでも設定可能。allowの代わりにsetfibというアクションルールを指定すれば良い。

# ipfw add 1000 setfib 番号 from any to any

この条件にマッチするパケットが指定された番号の FIB に割り当てられます。そしてルールの処理は、マッチしようがしまいが、そのまま直後のルールに続く。

ZFS Tips

anonymous@undisclosed.example.com (Anonymous) — Tue, 13 Sep 2022 02:35:02 +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 でした

グラフィックドライバ

anonymous@undisclosed.example.com (Anonymous) — Wed, 18 Mar 2020 07:29:52 +0000

グラフィックドライバ

はじめに

FreeBSD のグラフィックドライバの2020年1月頃の状況について記載します。サポート対象の FreeBSD は 12.1, 12.0, 11.3 です。この時点でのグラフィックドライバは過渡期にあり base にあるドライバ (legacy) から drm-kmod に移行しようとしています。将来的(13.0以降)には base のドライバは削除され、drm-kmod に一本化されます。

Intel グラフィック

Wikipediaにまとめられている通り、Intel Core アーキテクチャ世代から追加されたプロセッサ内蔵のグラフィックコントローラです。

これまで base にある i915kms.ko を読み込むことで利用できるようになっていました。 base にある i915kms.ko は現在 legacy と呼ばれ、Haswell 世代までのグラフィックコントローラをサポートしています。

このドライバのメンテナンスが年々難しくなり、Linux のドライバを直接利用する方向に舵を切ったことから、drm-kmod が誕生しました。こちらは GPL のソースコードのため FreeBSD の base には加えず Ports で提供されることになります。

drm-kmod は Ivy Bridge 世代以降のグラフィックコントローラで使用可能です。 Sandy Bridge または Westmere 世代のグラフィックコントローラを使用してる場合は base のドライバを使用してください。将来的に base のドライバは削除されますが、drm-legacy-kmod としてパッケージが提供されています。

drm-kmod は現在 Kaby Lake までの動作報告があります。また、手元で試した限りでは Coffee Lake (i7-8700) でも動作しました。

インストールは drm-kmod パッケージをインストールするだけです。

$ pkg install drm-kmod

ただし、2020年3月までは FreeBSD 12.1 に限り Ports からインストールする必要があります。これは Errata にもあるように FreeBSD 12.1 で発生した ABI 非互換のためです。 FreeBSD 12.0 がサポートされている間は 12.0 用にコンパイルされたバイナリが pkg で配られるため、12.1 では動きません。 2020年3月に 12.0 のサポートが切れるため、その後のパッケージバイナリは 12.1 用に作成されますので、12.1 でも pkg バイナリが利用可能になります。

drm-kmod をインストールすると、FreeBSD のバージョンに応じて以下の3つのいずれかがインストールされます。

drm-fbsd12.0-kmod
drm-fbsd11.0-kmod
drm-current-kmod

それぞれ 12.x 用、11.x用、FreeBSD-CURRENT用です。

drm-kmod はこれらのメタパッケージになります。 drm-kmod はビルド時にこれらのいずれかをインストールするように作成されますので、 pkg のリポジトリ毎に異なるバイナリが提供されています。そのため、11.x用のリポジトリからダウンロードした drm-kmod パッケージを 12.x で使うようなことはできません。

インストールが終わったら、/etc/rc.conf に以下の行を加えて起動時にロードするようにします。

kld_list="/boot/modules/i915kms.ko"

ports/pkg で入れるため /boot/kernel ではなく /boot/modules にインストールされます。現在のブートローダは /boot/modules にあるカーネルモジュールを優先的に読み込む機能がないため、同名のモジュールが /boot/kernel にあると必ずこちらを読み込んでしまいます。そのため、絶対パスで指定できる rc.conf で読み込むようにします。

次にグラフィック機能を使うユーザを "video" グループに入れます。

pw groupmod video -m <ユーザ名>

最後に X.org のグラフィックドライバを "modesetting" にして X を起動します。

Radeon グラフィック

drm-kmod は Radeon のグラフィックコントローラもサポートしています。こちらを利用するには上記のインストールが終わった上で、rc.conf に以下を記載して起動時にロードするようにします。

kld_list="/boot/modules/amdgpu.ko"

その他の設定は Intel グラフィックドライバと同じです。ユーザを "video" グループに入れ、X.org の "modesetting" ドライバを使用します。

Nvidia グラフィック

drm-kmod とは関係なく nvidia-driver を使います。グラフィックコントローラの種類により以下のいずれかのドライバをインストールします。

nvidia-driver
nvidia-driver-390
nvidia-driver-340
nvidia-driver-304

こちらも /boot/modules にインストールされますが、同名のモジュールが /boot/kernel にないため、ブートローダで読み込ませることができます。

X.org で使用するドライバに合わせて以下のいずれかを読み込みます。

カーネルモジュール	X.org のドライバ
nvidia.ko	nvidia
nvidia-modeset.ko	modesetting

ブートローダで読み込ませるには /boot/loader.conf に以下を追加します。

nvidia_load="YES"

または

nvidia-modeset_load="YES"

その後、対応する X.org のドライバを設定し、X を起動します。

上記以外のグラフィックドライバ

もし、上記のいずれのドライバも動作しない場合でも scfb ドライバを使用することができます。 scfb は FreeBSD の vt(4) によって管理されるフレームバッファを X から使用するためのドライバです。アクセラレーションはありませんが、FreeBSD が起動するマシンであれば必ず使用できます。

使うには xf86-video-scfb パッケージをインストールし、Xorg のドライバに scfb を設定します。

もし、コンソールが vt(4) でない場合には /boot/loader.conf に以下を設定し再起動してください。

kern.vty=vt

現在、どのコンソールドライバを使用しているかは "sysctl -n kern.vty" を実行し、結果が "vt" であれば vt(4) を "sc" であれば sc(4) を使用しています。

Xorg のドライバ設定

最近の Xorg は起動時に自動設定されるため xorg.conf を記述する必要はありません。しかし、自動設定でうまくドライバが認識されない場合や、意図的に指定したドライバで動かしたい場合にはドライバの指定を記述する必要があります。

このような用途の場合、xorg.conf を全て記述するのは面倒かつ、他の設定を間違える可能性があるため、自分が設定したい部分だけを設定します。

FreeBSD では /usr/local/etc/X11/xorg.conf.d に置かれたファイルを設定として読み込んでくれるため、ここにドライバの設定だけを書いたファイルを起きます。

例として driver.conf にドライバの設定を書いた場合を示します。

/usr/local/etc/X11/xorg.conf.d/driver.conf

Section "Device"
   Identifier  "Card0"
   Driver      "scfb"
EndSection

上記の例では scfb ドライバを使用するようにしています。その他の設定については自動設定されます。

パフォーマンス監視コマンド一覧図

anonymous@undisclosed.example.com (Anonymous) — Thu, 20 Jun 2019 08:23:23 +0000

パフォーマンス監視コマンド一覧図

FreeBSD のパフォーマンスチェックに使用するコマンド(iostat/fstat など)で、どのコマンドがどの機能をチェックできるかの一覧図を、Netflixでパフォーマンスアナリストを務めるBrendan Gregg氏がTweetしています。

古い情報ですが、どんなコマンドがあるかや、どのコマンドで調べられるかの参考になります。

図： https://pbs.twimg.com/media/B0uwdW6CEAI3cVi.png

Tweet: https://twitter.com/brendangregg/status/525707800584810496/photo/1

投機的実行に関する脆弱性への対処

anonymous@undisclosed.example.com (Anonymous) — Wed, 25 Dec 2019 09:03:54 +0000

投機的実行に関する脆弱性への対処

Spectre/Meltdown に代表されるCPUの脆弱性に関する対処方法です。

Spectre Variant 1

対策

2019年12月現在 FreeBSD での対処方法はありません。

Spectre Variant 2

対策

CPU feature のIBRS を有効にします。またはカーネルを含む実行ファイルを retpoline を有効にしてコンパイルしなおします。どちらもデフォルトでは無効です。

準備

事前にマイクロコードアップデートが必要です。

対処方法

sysctl で hw.ibrs_disable=0 を設定します。

または、clang に -mretpoline を渡してコンパイルしなおします。

無効化方法

sysctl で hw.ibrs_disable=1 を設定します。

または、clang に -mno-retpoline を渡してコンパイルしなおします。

Meltdown (Spectre Variant 3)

対策

カーネルに実装されている PTI (Page Table Isolation) を有効にします。 PTIはデフォルトで有効になっています。

準備

11.2 以降の対応済のカーネルを用意します。

対処方法

sysctl で vm.pmap.pti=1 を設定します。

無効化方法

sysctl で vm.pmap.pti=0 を設定します。

Spectre Variant 4

対策

CPU Feature の SSBD を有効にします。デフォルトでは無効です。

準備

マイクロコードアップデートが必要です。

対処方法

/boot/loader.conf に以下を指定します。

hw.spec_store_bypass_disable=2

値の意味は 0:off 1:on 2:auto です。

無効化方法

/boot/loader.conf に以下を指定します。

hw.spec_store_bypass_disable=0

Lazy FPU

対策

2019年12月現在リリースされているカーネルは全て対策済です。

L1 Terminal Fault

対策

CPU Feature のL1DFLを使うか、ソフトウェアでL1Dキャッシュをクリアします。デフォルトでは無効です。

準備

マイクロコードアップデートを行います。アップデートしなくてもソフトウェアの実装が使用されます。

対処方法

/boot/loader.conf に以下を指定します。

machdep.syscall_ret_flush_l1d: 1

値の意味は次の通りです。

0:off 1:0n 2:hw 3:sw

無効化方法

/boot/loader.conf に以下を指定します。

machdep.syscall_ret_flush_l1d: 0

Microarchitectural Data Sampling (ZombieLoad)

対策

CPU feature の　MD_LOAD を有効にします。デフォルトは無効です。

準備

マイクロコードアップデートが必要です。

対処方法

/boot/loader.conf に以下を設定します。

machdep.hyperthreading_allowed=0

その上で sysctl で hw.mds_disable=3 を指定します。

数字の意味は次の通りです。

0 - mitigation disabled
1 - VERW instruction (microcode) mitigation enabled
2 - Software sequence mitigation enabled (not recommended)
3 - Automatic VERW or Software selection

無効化方法

sysctl で hw.mds_disable=0 を指定します。