FreeBSD 10.1-RELEASEな自宅ファイルサーバからMacにファイルをコピーすると「予期しないエラーが起きたため、操作を完了できません（エラーコード -50）。」が発生してコピーに失敗する現象に長らく苦しめられていた。経験的にファイルサイズが大きいほど発生確率が高く、数百MBくらいまでのファイルなら問題ないが、2GBを超えるとまずアウトっていう。鯖→Macの場合AFP(Netatalk 3.1.7)でもCIFS(Samba 4.2.5)でも発生し、鯖→Windowsの場合は言うまでもなくCIFSしか使えないが、所々詰まりながらも一応成功するといった具合。

失敗時はNetatalkのログに「Cannot allocate memory」が必ず記録されている。発生場所は大体{fork.c:913} (error:AFPDaemon): afp_readか{dsi_stream.c:424} (error:DSI): dsi_stream_read_fileのどっちか。メモリたんねーと言われましても、32GB積んでるtopで見ても余裕のよっちゃんイカで数GBレベルで残ってますし…。もう全くわけがわからないよ！本格的に原因を探ろうとsshで各種情報をモニタリングしながらコピーしたら、今度はsshdまでCannot allocate memory吐いて接続切れるし……。

ドライバの不具合？NIC/L2SW由来の不具合？？もしかしてケーブルが腐ってる？？？などなど、疑心暗鬼ロードを爆走していたが、ようやく、ついに！遂に！！原因がわかったッ！！！！

犯人はヤス何とVirtualBox。 VirtualBox実行中はnetgraph関連のメモリが不足しやすく？なるっぽい。ここやここで同症状が報告されており、/boot/loader.confにnet.graph.maxdata=65536を追加すればおｋと書いてあった。

このカーネルパラメータはnetgraphのデータキューの最大確保数を表すものらしい。同様に非データ用のnet.graph.maxallocなんてのもある。それぞれ/usr/src/sys/netgraph/ng_base.cで定義されていて、コメントが若干怖いことが書いてあった。

static int maxalloc = 4096;/* limit the damage of a leak */
static int maxdata = 512;  /* limit the damage of a DoS */

下手に大きくすると問題発生時に被害が拡大しそうな雰囲気。ま、外部公開してなきゃそんなに気にしなくてもいいだろうけど。

ついでにdmesgにLimiting open port RST response from 208 to 200 packets/sec.なるログも出ていたので、/etc/sysctl.confに以下を追加。

net.inet.icmp.icmplim=2000

肝心のloader.confも一応。

net.graph.maxdata=65536
net.graph.maxalloc=65536

上記設定で1～6GBほどのファイルを100GB分くらいコピーしてみたら、何の問題もなく完了した。普通に動くって素晴らしい。

• Network problems while running VirtualBox
• Write failed: Cannot allocate memory
• (FreeBSD) bacula-fdが ERR=Cannot allocate memory というエラーを出す - ttt
• NETGRAPH(4) - 特殊ファイル - YOS OPENSONAR
• apache負荷対策 | ガイドミー管理者日記

システムドライブがダイナミックディスクの場合、Intel(R) Rapid Storage TechnologyのSSDキャッシュ機能が使えない予感。確かな文献がないため、環境依存なのかそういう仕様なのかは不明だが、少なくとも自分の環境では“ソリッドステートドライブを使用して高速化”のメニューが出てこなかった。

ベーシックディスクに戻すと出現するので、きっとそういうモンなんだろう。

ちなみに、ダイナミックディスク→ベーシックディスクの非破壊変換は、TestDiskを使うと比較的簡単かつ安全に出来る。“安全”とは言っても、一歩間違うとWindowsが起動しなくなるばかりか最悪データの消失に繋がりかねない。細心の注意と自己責任で以てよろ。良い子のみんなは業務用PCなんかで挑戦しちゃダメだぞ★。ぼくはかいしゃのぱそこんでためしてきどうしなくなってちょうあせったよ。

IRSTの効果はというと、体感レベルで結構効いてる感じ。キャッシュ有りの環境になれた後でキャッシュを切って試してみると、ものすごーく遅い。正直、効果の面でも運用の面（データの保全は大丈夫なのかとか？）でも懐疑的だったけど杞憂ですた。自分より遥かに頭の良い人達が開発してるんだから疑うほうが失礼か。

このIRSTで地味に凄いのが、キャッシュのON/OFFをOSの再起動なしで出来るという所。稼働中のシステムHDDにSSDをくっつけた仮想ボリュームを作り、元のHDDとオンラインで丸ごと差し替えるとか中々狂ってる。ZFSみたいにファイルシステムレベルでキャッシュ機能を持ってたり、非システムディスクならともかく、デバイスレベルで丸ごと差し替えですよ？人間で言ったら生きたまま心臓を交換するようなもんですよ？IntelもWindowsもすげーと言わざるをえない。

ところで俺のRAID-Zを見てくれ。こいつをどう思う？

[Decomo@Freyja ~]$ zpool status 
  pool: zdata
 state: UNAVAIL
status: One or more devices are faulted in response to IO failures.
action: Make sure the affected devices are connected, then run 'zpool clear'.
   see: http://illumos.org/msg/ZFS-8000-HC
  scan: resilvered 121G in 2h0m with 13047163 errors on Thu Sep 24 23:26:28 2015
config:

	NAME                       STATE     READ WRITE CKSUM
	zdata                      UNAVAIL     96     0     0
	  raidz1-0                 UNAVAIL    194     0     0
	    11774477246658925336   REMOVED      0     0     0  was /dev/ada0p1
	    ada1p1                 ONLINE       0     0     0
	    replacing-2            UNAVAIL      0     0     0
	      3139585788591315191  UNAVAIL      0     0     0  was /dev/gpt/data0-1a
	      ada2p1.nop           ONLINE       0     0     0
	  raidz1-1                 ONLINE       0     0     0
	    ada5p1                 ONLINE       0     0     0  block size: 512B configured, 4096B native
	    ada3p1                 ONLINE       0     0     0  block size: 512B configured, 4096B native
	    ada4p1                 ONLINE       0     0     0  block size: 512B configured, 4096B native
	logs
	  mirror-2                 ONLINE       0     0     0
	    ada10p4                ONLINE       0     0     0
	    ada15p4                ONLINE       0     0     0
	cache
	  ada10p5                  ONLINE       0     0     0

errors: 13047165 data errors, use '-v' for a list

すごく・・・UNAVAILです・・・。

RAID-Zを使い始めて早4年、遂にうちにも訪れてしまった、この恐怖の現象「RAIDリビルド中のHDD死亡お替わり」が。いつの間にかデグレってた事は何度かあったけど、UNAVAILは初めて見たよ……。幸いにもada0は脱落しただけで死んではおらず、SATAケーブル＆電源抜き差しで無事復活というかresilveringなう(๑˃̵ᴗ˂̵)وなんですけども。心臓に悪いったらありゃしない。

それにしても、SATAコネクタの信頼性の低さはどうにかならないかなー。コンシューマ向けのHDD×7台でRAID組んでるのがそもそもの間違いではあるし、信頼性求めるならSAS使えって話でもあるけどさ、流石に家庭でSASはやり過ぎっつーかオーバースペックも良いとこでしょ。そんな金もないし。このあたりのイレギュラーさを差し引いても、SATAコネクタは緩み易過ぎると個人的には思う。もうちょっとガッチリとはまって欲しいもんだ。

とか何とか言ってるそばから、またada0が脱落してるし……。

無事リビルド完了（念のために言っておくと作業自体は随分前に終わってる。）

面白いログが取れたので記念ぱぴこ。

[Decomo@Freyja ~]$ zpool status zdata
  pool: zdata
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
	continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Sat Sep 26 13:42:23 2015
        4.51T scanned out of 14.7T at 376M/s, 7h51m to go
        968G resilvered, 30.78% done
config:

	NAME                       STATE     READ WRITE CKSUM
	zdata                      DEGRADED     0     0     0
	  raidz1-0                 DEGRADED     0     0     0
	    ada12p1                ONLINE       0     0     0  (resilvering)
	    ada1p1                 ONLINE       0     0     0
	    replacing-2            DEGRADED     0     0  370K
	      3139585788591315191  UNAVAIL      0     0     0  was /dev/gpt/data0-1a
	      ada2p1               ONLINE       0     0     0  (resilvering)
	  raidz1-1                 ONLINE       0     0     0
	    ada5p1                 ONLINE       0     0     0  block size: 512B configured, 4096B native
	    ada3p1                 ONLINE       0     0     0  block size: 512B configured, 4096B native
	    ada4p1                 ONLINE       0     0     0  block size: 512B configured, 4096B native
	logs
	  mirror-2                 ONLINE       0     0     0
	    ada14p4                ONLINE       0     0     0
	    ada15p4                ONLINE       0     0     0
	cache
	  ada14p5                  ONLINE       0     0     0

errors: 4503902 data errors, use '-v' for a list

RAID-Zを構成するHDDが2台同時にリビルドされてた。流石ZFS、なかなか器用なことをしてくれる。これもブロック単位でチェックサムを持ってるお陰なのかしら？

ASRock C2750D4Iは8コアAtom C2750搭載でSATAポートが12個もある、正にファイルサーバにうってつけのマザボである。Mini-ITXながら通常サイズのDDR3 DIMMが4本刺さり、やろうと思えば16GBモジュール×4で64GBものメモリが積めるのも素晴らしい。これまた大食漢のZFSにおあつらえ向きの仕様で、加えてIPMIでリモートで電源ON/OFFやBIOSがいじれたりして、刺さる人には刺さりまくりの素敵ママンだ。流石は変態紳士ASRock。

発売当初から目は付けていたものの、4万後半という値段に手が出せないまま円安と増税の影響で更に値上がりし、もう買えない…と諦めかけていたその時！偶然、JMC DirectでB級品が35000円弱で売られているのを見つけてしまったので光速でポッチッチ。

家鯖のFreeBSD 10.1-RELEASE環境はそのままに、早速Z77A-GD65 + Xeon E3-1260Lと入れ替えてみたところ、難なく動いた。

……と思ったのも束の間、portsで入れたソフトが軒並みIllegal instructionで落ちまくる！CPUTYPE?=nativeでコンパイルしたバイナリなので、Avotonじゃ実行できない命令が生成されてるんだろう。SandyBridgeからのグレードダウンとはいえ、同時期のCPUで実行できないほどのアグレッシブなコードを吐くclang先輩マジぱねっす。C2750用にビルドし直そうとしても、これまた軒並みIllegal instructionで落ちまくり。ツールチェイン、お前らもか……。たかがgmakeですら超最適化してくれるclang先輩マジ(ry

怪しそうなportsを片っ端からリビルドしたり、gdbで落ちてるライブラリを探ったり、どうしても分からん時はpackagesに逃げたりして何とか再構築できた。最適化ビルドも考えものだな…。少なくともカーネルを再構築する時は、無難な最適化オプションにしないと泣きを見そう……。そのためのCPUTYPE?なんだろうし（?付きの方はカーネル構築時には適用されないらしい）。

仮想マシン上のWindows 7 (64bit)のWindows Updateを1年ぶり位にやってみたら全然進まないでやんの。更新件数は113件程とそこそこあり、ホストが貧弱Avoton Atomとはいえ、半日放置しても「更新プログラムをダウンロードしています」が0%からピクリともしないのは流石におかしい。一番ボトルネックになりそうなストレージは仮にもSSDだし。

止むなく一旦キャンセル→再起動からの再実行してみたら、今度は最初の「更新プログラムを確認しています」から進まなくなった＼(^o^)／

それから色々やってみて、何とか無事更新が出来たが、超絶時間がかかった。取りあえず、効果があったと思われるのは以下のもの。

• x64 ベース システム用 Windows 7 のシステム更新準備ツール (KB947821) [2014 年 10 月]
  • 32bit版はこっち
• Windows Update エージェントを最新バージョンに更新する方法

システム更新準備ツールを実行し（これが超時間食いで終了まで半日くらい掛かった）、Windows Updateエージェントを最新にして、もう一度システム更新準備ツールを実行（今度は2〜3時間で終了）した所、うちの環境では問題が解決した。それでも最初のWindows Updateが完了するまでは更に数時間かかったけど…。

BITSのトラブルシューティングやWindows Updateのキャッシュのクリアは然程意味がなさそうに思えた。特にキャッシュのクリアは意味がないどころか、逆に悪影響な気がした。どちらも何の根拠もない私見なので悪しからず。

しっかし、何もしてないのにOSの最重要コンポーネントがおかしくなるのは止めてもらいたいもんだね。Windows Updateがぶっ壊れるだけならまだいいが、ぶっ壊れた結果、関連のバックグラウンドタスクがCPUとメモリをバカ食いするのが頂けない。CPUを常時25%のメモリ2GB超を持ってくんだから、貧弱マシンにゃ辛いのよ（それでWindows Updateの不具合に気付いたのだけども）。最近頻発してるらしいし、どうしちゃったのゲイツ。

まぁ、1年も更新を怠るなって話ではあるが…。

• (2015年4月～8月版)Windows Updateがはじまらない、終わらない、失敗する問題
• Windows Updateが遅い、進まない、終わらない、失敗する問題の解決方法