2025-08

フィクションのネタバレ

私も小説などは時折読みます。書籍として買うこともあります。フィクションものはネタが事前に割れているものしか買いません。一度目を通しただけで終わるものに、わざわざお金を掛けるのは無駄なような気がしているからでもあります。それでも、繰り返し読む本はさほど多くないという現実があります。

世間的にはネタバレを避ける風潮があります。なぜ私はネタバレしても良いとするのか。それは、小説やコミックの世界には、魑魅魍魎(ちみもうりょう) を描くことを好む作家が存在しているからです。私はそのような魑魅魍魎(ちみもうりょう) が描かれた作品を読みたいとは思いません。どうせ読むなら心地よくなれるものを読みたいと思うものです。読みたくないものを掴まないためには、事前にウィキペディア等を眺めてネタバレを仕入れるのが最善の選択だという訳です。

Linux distroのアップデート

Linux distroをアップデートした後は再起動が必要です。そもそもですがFedoraのGUI環境は再起動が不要になるように設計されていません。他のdistroでも事情は同様だと思います。 Oracle Linuxはkspliceを謳っていますがこれは有償販売されるオプションです。緻密に検証されていない限り「再起動は必要」というのが基本的な姿勢です。いくつかのデーモン類はアップデート時に勝手に再起動されますが、それは単にピンポイントでそうなっているだけです。システム全体に通用する一般論ではありません。

昔はサーバの再起動といえばpingに応答しない時間が長く結構待たされてしんどい作業でした。仮想化が進んだ昨今はさくっと再起動できます。ビジネスであっても、たとえミッションクリティカルであっても、アップデートをしたのであれば有無を言わさず確実に再起動をスケジュールしましょう。

10Gスイッチの罠

10GでLANを組む場合に注意しなければならないことがあります。

基本的にRJ45+UTPを採用する10GBASE-Tはとても熱くなります。熱くなるということは強制空冷しなければいけないということでもあります。昨今の半導体事情から言うと、10GBASE-Tを採用するなら最低でも2.5W/portは覚悟しなければなりません。 8portのスイッチであれば20WもPHYに掛かります。もしこれが光ファイバ配線であれば0.7W/portで済むため、8portすべて使ってもPHYの電力は5.6Wで済みます。この差は、スイッチがファンレス設計かどうかに直結する、とても大きな差異です。

10Gのセグメントでは、いや1Gの時代から、ジャンボフレームが必要になります。ジャンボフレームは無線LANのブリッジとは相性が悪く、共存することができません。なのでLANを分割することが当たり前のように行われます。ここでルータのポート数を必要な分だけ揃え、さらにスイッチを複数買い揃えることができるかどうかが勝負になります。数を買い揃えることができないのであれば、VLANに対応したスイッチが必要です。 PCルータを組む場合はPCIeスロットの数を得ることが難しく、 10Gのポートは2本までとなるのが普通です。サーバ用のちょっと高級なメインボードを使っても4本までが限度でしょう。ヤマハのRTX1300を持ってきても10Gのポートは2本しかありません。

10G LANの主な用途としては、1G LANを任意数束ねたもの、というぐらいの立ち位置が普通だと思います。これを実現するには、ルータもスイッチも、タグVLANによるトランクに対応していなければなりません。ところで市販のご家庭用のスイッチはアンマネージドな製品が普通であり、タグVLANの付け外しには対応しません。発売が開始されたからと言ってダムスイッチで良いとするのは早計です。

NTP servers

宅内にローカルNTPサーバは何台必要か? という件については、基本的には物理サーバでも仮想サーバでもいいので2台以上が必須です。ご家庭なら1台あれば十分だろうという考えがあるとは思いますが、それは違います。

NTPサーバが2台以上が必要という要件には、 NTPクライアントが2台以上の親を見つけないとNTPクライアントが自らの時刻を同期しようとしないから、という理由が背景にあります。 WindowsのようにNTPではなくSNTPで稼働するクライアントのみを捌けば良いなら、時刻の同期はなくステップ校正のみなので1台で十分です。 LinuxなどはWindowsとは異なり正統派のNTPクライアントを搭載しています。これらについて単一サーバを許すように各NTPクライアントを「特別に」設定して回るのは面倒なことです。細かいことを考えなくても良いように、推奨に従って、仮想でもいいから2台以上のNTPサーバを用意しておくことがお勧めの選択となります。

時計の同期は物理サーバで提供することが望まれます。しかし精密な同期が必要なことは稀なのも確かであり、実用上は仮想サーバでも通常は十分です。仮想サーバとする場合は同期がループしてややこしいことにならないように注意する必要があります。

上流をどこに設定するかは悩ましい問題です。 IPv4サービスとしてはntp.nict.jpがダントツで優秀です。しかしIPv4は仮想化が進んでおりミドルボックスが多い関係から混雑しやすく、ネットワーク的に遠いと考えられる場合があります。 NTT回線経由で利用するのに便利なIPv6サービスとしては、ntp[1-3].v6.mfeed.ad.jpが優秀です。

ZFS on NetBSD 10

NetBSDのZFSコードは非常に古く、 vdevをcreateするときのmetaslabの単位サイズが肥大化するという不都合があります。 200分割の端数なのでおおよそvdevの0.5%が端数として切り捨てられ、暗黙のうちに不使用領域となります。ほとんどのユーザはこの0.5%の無駄を許します。

個人的には、24TiBのpoolで実装される128GiBの無駄は絶対値として大きすぎ、贅沢が過ぎると考えています。 OpenZFSは16GiBのmetaslabを標準として設定し、これで2PiBまでのvdevをサポートします。概算としてはvdevのサイズが512TiBに到達するまでは、4GiBのmetaslabを固定的に設定しても大丈夫のはずということになります。ハードディスクのサイズは成長しなくなっていますので、これでも当面は大丈夫です。

次のパッチはNetBSD 10に適用されるものであり、metaslabのサイズを最大4GiBでクランプします。

RCS file: /cvsroot/src/external/cddl/osnet/dist/uts/common/fs/zfs/vdev.c,v
retrieving revision 1.6.10.1
diff -u -r1.6.10.1 vdev.c
--- dist/uts/common/fs/zfs/vdev.c       18 Nov 2024 19:48:09 -0000      1.6.10.1
+++ dist/uts/common/fs/zfs/vdev.c       12 Aug 2025 18:10:24 -0000
@@ -1733,6 +1733,7 @@
         */
        vd->vdev_ms_shift = highbit64(vd->vdev_asize / metaslabs_per_vdev);
        vd->vdev_ms_shift = MAX(vd->vdev_ms_shift, SPA_MAXBLOCKSHIFT);
+       vd->vdev_ms_shift = MIN(vd->vdev_ms_shift, 32); /* clamp at most 4GiB */
 }

 /*

vdevのサイズは標準的には200で割られてから端数を切り捨て、その結果がmetaslabの単位サイズになります。単位サイズは最低でも16MiB未満となることができません。そうなる条件は3200MiBつまり約3.3GBのハードディスクを使った場合なので、下限としては今どき忘れても良いでしょう。単位サイズが4GiBに到達するのはvdevが800GiBに到達した場合なので、換算すると約858GBのハードディスクを使った場合です。いまどきのハードディスクとして8000GB程度など当たり前であることを考えると、クランプすることは現実味がある数字であることがわかると思います。

ZFSでパッチしたいパラメタを設定している箇所はもうひとつあります。 ZFSは既定で、全体の3.5%ほどの空間を、ファイル削除関連のCoW操作のために予約します。計算するとわかりますが24TiBのpoolでは768GiBにも及びます。ファイルの削除操作にテラバイト級の予約領域が必要だなんてことはおよそ考えられません。安全のために予約されているとはいえ、いくらなんでも大きすぎです。なので、これも小さく抑える対象にします。順次的にファイルを削除するのに4GBもあれば救済は可能であろう、と考えてその程度に絞ります。 OpenZFSの標準は保守的に設計されており、最大に膨れたとき128GiBとされています。

次のパッチはNetBSD 10を想定しており32分割の1を予約する代わりに4096分割の1を予約します。

RCS file: /cvsroot/src/external/cddl/osnet/dist/uts/common/fs/zfs/spa_misc.c,v
retrieving revision 1.5
diff -u -r1.5 spa_misc.c
--- dist/uts/common/fs/zfs/spa_misc.c   7 May 2019 08:51:09 -0000       1.5
+++ dist/uts/common/fs/zfs/spa_misc.c   13 Aug 2025 11:48:53 -0000
@@ -458,7 +458,7 @@
  *
  * See also the comments in zfs_space_check_t.
  */
-int spa_slop_shift = 5;
+int spa_slop_shift = 12;
 SYSCTL_INT(_vfs_zfs, OID_AUTO, spa_slop_shift, CTLFLAG_RWTUN,
     &spa_slop_shift, 0,
     "Shift value of reserved space (1/(2^spa_slop_shift)).");

16TiBのvdevにおいて4GiBのslop spaceが設定される計算です。 4GiBのslop spaceで足りるのかということを考えてみます。 slop spaceの最小値はもともと128MiBであり、これはもともとの設計通り32倍して4GiBのdatasetに相当します。 128MiBの空き領域があれば4GiBのファイルまたはdatasetを削除する程度のことはできると読むことができます。このままリニアに外挿換算すると、先に示した4GiBの空き領域があれば128GiBのdatasetまでは余裕を持って削除できると読めます。基本的に切羽詰まったpoolのファイルをちまちま削除している余裕はないのであり、 vdevを追加するか入れ替えるかのどちらかしか選択肢がないのが普通です。ですから最悪でpoolがread onlyになっても、そんなもの、と考えておいたほうが良いでしょう。

このあたり、ZFSのパラメタ設計は論拠が乏しいというか精密さを感じないですね。現実の課題がpower of 2で割り切れるほどシンプルだとは思えないです。未使用領域や空き容量に関する議論が雑すぎないだろうかという気がします。ストレージは最低限20%ぐらいは空けて使うのが当たり前なのも事実なので、細かい計算をしても空きは空きなのですが。

NAS server example

下記条件でおおよそ100〜150Mbyte/secのシーケンシャルな書き込み速度が出せます。 2.5Gbps LANで構成されたご家庭用のファイルストレージとしては、概ね満足なスペックだと思います。

NetBSD 10 + samba4 software stack
Intel Celeron N3125 processor
Intel i225V network interface
16GB memory
SATA SSD (128GB) x1; OS + ZFS SLOG
SATA HDD (CMR, 8TB, 5400rpm class) x3; ZFS RAIDZ1

今どきの選択としては、類似品を組み立てるなら市販NAS箱で選定されているとおりに Intel Celeron J4125が妥当です。ただし、そのような板はほとんど市販されていません。

HDDが故障した経験はほとんどありません。とはいえ、いざ壊れたときバックアップからリストアするために時間を奪われるのは思っている以上に面倒で煩わしい展開なので、最低限でもRAID1かRAIDZ1は組みましょう。 NetBSD ZFSはSSDをサポートしませんので、メインストレージにSSDを持ってくるのは辞めたほうが良いでしょう。

Why use ZFS

なぜ我々はZFSを使うのか? btrfsの将来には期待しますが、なぜbtrfsに実用的なRAID5が無いことが致命的なのか、を考えてみましょう。

そもそもRAID5/6は必須の機能: RAID1のスピード自慢は有名です。しかし極小零細サーバであるとか、ハイブリッド構成であるとか、格安サーバのブートドライブでもない限り、 RAID1を組むことは現実にはあまり選択されません。 RAID1で十分というのは、零細サーバでは最初からHDDが2本しか積めないところから来ている問題です。一般的には、NASとして構築される集中ストレージであればデータ保管用としてはRAID5/6が選択されることが普通です。
compressionはそれなりに有用: UN*X系OSのファイルシステムに保存される、ユーザのデータは多くがテキストで構築されています。これらは圧縮しやすい性質を持ち、実際に圧縮されることが望まれます。 x86のバイナリですら圧縮の対象になります。圧縮できるものはしたほうが良い、ということには違いありません。圧縮後にどれだけストレージに余裕ができたかを確認しておくのは通常の要求ですが、 dm-vdoのような追加レイヤーでは基礎的な要求に対応ができないため、ファイルシステムのレベルで圧縮機能が統合されている必要があります。ファイルシステムのサポートがあるZFS, NTFSを使うのでもなければ圧縮という選択肢は出てこないのも一般的です。
統合されたvolume managementはそれなりに有用: そもそもdevice mapperの上位に置かれることの多いXFSはshrinkできません。 ext4を使いたいかと言われれば否でしょう。もっとも、ZFSでもattach/detachは望まれた操作ではありません。 ZFSに関して言えばrebalancingも含めて将来的には実装される方向だろうと思います。 LVM2を始めとする管理が複雑なストレージスタックを使うよりは、管理がシンプルなZFSを使ったほうが幸せである可能性は高いです。
スパースファイルに適する特徴を持つ: ZFSはオールゼロのデータブロックをディスクに書き込みません。これは通常は好都合な性質です。

私が知る限りビジネスユーザはハードウェアのカードで実現されたRAID5/6で満足しています。ビジネスとしては、開発に介入してまでLinux btrfsにRAID5をもたらすメリットがありません。同じく、RAID1が主体となる零細サーバを扱う個人開発者がRAID5に興味を持つことは少ないでしょう。そうなるとbtrfsにRAID5がもたらされる可能性は、言われているほど高くはありません。 HBAによるソフトウェアRAID5を狙うなら、RAIDZが提供されるZFSを使ったほうが現実的です。

NetBSD 11 BETA

NetBSD 11が分岐しました。今後安定化修正を経てリリースされるものと思いますが、 NetBSD時空では早くても2026年にならないとリリースされないのではないかと思います。進捗としてはデバイスドライバが若干充実したぐらいであり、目新しいニュースはありません。 BETAの安定化が一定程度進んだところでNetBSD 10から乗り換えれば良いでしょう。

NetBSD ZFSがメモリ圧迫されたときにロックアップする現象が公式で告示されています。しかし、NASサーバとして運用する場合は余計なプロセスは動かしません。チューニングで下手なことをしなければ、恐らく生産的な用途に利用しても大丈夫です。 /etc/daily でロックアップしない程度というと updatedb も絡むためプールサイズにも依存するのだとは思いますが、 4GBから8GB程度をトラディショナルなバッファキャッシュとユーザランドのために空けておけば十分ではないか、と思います。個人的には、NetBSD ZFSを動かすとき16GB以上の物理メモリを準備しています。

Serial port flow control

シリアルポートではRTS/CTSをハードウェアフロー制御に使います。私が知る限りIntel i8251が始祖に近い存在です。 i8251は場合はハードウェアフロー制御のうちCTS入力による送信抑止は強制であり、任意ではありませんでした。 IBM PCに源流をもつ、いまどきのパソコンのi8250/NS16550系統は、一般的にフロー制御はソフトウェア対応です。

いまどきのシリアルポートの用途はリアルタイム制御が主であり、フローを目一杯流し込むことをしません。それであればFIFOはほとんどいらないという現実があります。かわりに割り込み処理が重たくなるので、パソコンの出先にマイコンが必要になるのです。

Local Router

ジャンボフレームを採用したNASセグメントと通常の無線LANセグメントの間を結ぶには、通常はMTUの境界点にルータが必要となります。 YAMAHA NVR510を始めとするヤマハルータの多くはジャンボフレームをサポートしないため、 MTU境界中継ルータの目的で使うことができません。 RTX1300はジャンボフレームをサポートしますが予算オーバーですし、さらに言えば性能が若干足りません。 RTX1300がインターネット接続用に設計されたルータであるという立ち位置はまだ変えられないようです。

とりあえず低予算で、という制約のもと10Gbpsクラスのローカルルータを組むには、VyOSが便利です。 NetBSD+npfも検討はしましたが、NetBSDではNAT66の実装が実用水準にないため、採用には厳しいという判断となりました。