LED照明には以前から興味があったが、普通の蛍光灯ならまだしもインバータ式を置き換えるに足る理由がなく、今まで無縁の生活を送っていた。

しかし連日の酷暑で部屋の温度も急上昇。蛍光灯からの熱線がジリジリと熱いような気がしないでもなかったので、赤外線を殆ど含まないというLED照明に俄然興味が出てきた。

冷やかし半分に価格.comを見ていたところ、NECのLEDシーリングライトHLDZD1251がスペックも値段も他の同クラスの製品より頭一つ出ており、楽天の期間限定ポイントもあったため、そのままお買い上げ〜。部屋のサイズ的には〜8畳までのHLDZB0849でも大丈夫そうだったが、「スペックの割に暗く1つ上のモデルで丁度良い」というレビューがあったのと、大は小を兼ねるって訳でHLDZD1251を選んだ次第。

折角なので今まで使っていたインバータ式蛍光灯HHFZ4160と色々比較してみた。

スペックを見比べると、最近のLED照明は数値の上でも蛍光灯に匹敵する性能を有している事が分かる。LED照明と蛍光灯では全光束の定義が違う¹⁾ため、数値が小さい＝性能が劣っているという訳ではない。だが、一般消費者はそんなムツカシイ事を知っているわけもなく、数値の単純比較でLEDの方が劣っていると判断してしまうだろう。

数値的にも蛍光灯に追いついたことで、こうした不本意な比較による購入機会の損失は避けられるし、実際の性能もそれだけ上がっていると言える。演色性も蛍光灯と遜色なくなっており、Raが70台で「LEDは色が悪い」と言われていた頃とは隔世の感がある。

ワットチェッカーで消費電力を計測した。

明るさ最小の時で11W、最大の時で30Wもの差が出た。ただし、LEDの最小は蛍光灯より明らかに暗く、割と暗めが好きな自分でも暗いと思ってしまうレベルなので実用にならないと思われる。一方で、蛍光灯の最小も暗いは暗いが、何とか実用になるレベルの明るさはある。

普段使いは、自分が定常的に使っている明るさでの消費電力。感覚合わせなので厳密に同じ光量ではないだろうが、LEDの方が17Wの節電という結果になった。これで元を取ろうと思うと、1週間あたりの使用時間を36時間（平日5日×4時間＋休日2日×8時間）として、1年間52週の節約電力は31.8kWhとなる。24円/kWhとして年間の節電料金は763.7円/円なので、9.3年という計算に…。一人暮らしだとこんなもんすかね。

グラフのサンプル数の違いは調光機能の差によるもの。

HLDZD1251 (LED)は5段階調光の値で（連続調光も可能だが面倒なのでやってないｗ）、逆にHHFZ4160 (蛍光灯)は連続調光しかないので調光ボタンを1度押した時の値を記録している。手動押下なので若干のバラつきがあると思われる。

照度計などというハイテク機械は持ってないので、一眼レフカメラで露出を固定し撮影した。

撮影条件：PENTAX K-5, 1/20, F4.0, WB=N:昼白色, JPEG縮小加工のみ

スペック上はHLDZD1251 (LED)の方が演色性が高く色温度は暖色寄りとなっている。

しかし実際の色味感覚としては、明らかにHHFZ4160 (蛍光灯)の方が演色性が良い。HLDZD1251は青白い光で、物が淡泊な色合いに見える。肌色が特に顕著で、HLDZD1251の下では青白く不健康な見え方になる。黄色あたりのスペクトルが抜け落ちてる感じ？これはちょっと頂けない。

ブレーカーを間違って落とした（電気使いすぎとかじゃなくて本当に間違ってスイッチを落とした）ら、家鯖のマザボZ77A-GD65のBIOSが飛んだ(´・ω・｀)

電源入れていつまで経ってもサーバに繋がらず、モニタを繋げてみると「No Signal」。コールドブートしても「No Signal」。

マザボのデバッグ用LEDのコードを見ると、55と表示された後に03に戻る事を繰り返していて、コード表と照らし合わせるとメモリの初期化段階で落ちてるっぽい。ならば必殺メモリ抜き差し！をしてみるも「No Signal」。ああ無情。

メモリ交換か、はたまたM/B交換か…と考えつつ、ふとBIOSの切り替えスイッチでBIOSを切り替えてみたら起動した！

予期せぬ電源断でBIOSが飛ぶことがあると噂に聞いたことはあるが、本当にあるとはねぇ…。まぁ、元々BIOSのフラッシュROMがヘタってて、このタイミングでお亡くなりになったという可能性もあるけど。頻繁に書き換える物でもないし、そう簡単にROMがヘタるか？という疑念はあるけども。何度か再プログラムを試みるも症状は改善しないので、マジ死亡っぽい。

とりあえず、デュアルBIOSで助かったぜ、というお話。

最近知ったのだけど、CrucialのSSDのNCQなTrimコマンドにはバグがあるらしく、Linuxではブラックリスト入りしてる模様。このバグを踏むと、SSDがビープ音を発しデータがぶっ壊れるそうな((((；ﾟДﾟ))))

フォーラムとブラックリストを見る限り“QUEUED”なTrim固有の問題のようだが、ここによれば“non-QUEUED”なTrimでも起きると書いてある。どっちが本当なんだ…？

他に情報をあたってもLinux以外のOSでの回避方法やら発生報告は見当たらないし、良く分からん。シェアからしたらWindowsでの報告があっても良さそうだけど、例え本当にバグ要因のデータ消失が起こっていたとしても、寿命要因でのクラッシュくらいにしか見られて無さそう…。

そもそも、TrimのQUEUEDとnon-QUEDEDって何やねんって話だが、要はNCQに対応してるかどうかの違いみたい。当初、Trimコマンドは非NCQなコマンドとして規定され、その後Serial ATA Revision 3.1でNCQ版が登場したという歴史のようだ。もしかして、バグの原因はNCQでコマンドが並べ替えられた結果、データ読み込み要求よりTrimコマンドが先に発行されて、データがぶっ壊れるというオチだったりして？（流石にこんな単純なバグではないだろうけど）

とりあえず、うちではCT960M500SSD1を1年ほどMacOS XでTrim有効の状態で使っていたが、バグったことはない。ついでに現在進行形でCT128M550SSD1をFreeBSDでTrim有効で使っているが、今のところ問題は出ていない。

• M500/M5x0 QUEUED-TRIM data corruption alert (mostly for Linux users) - Crucial Community
• linux/libata-core.c · torvalds/linux · GitHub
• Trim (computing) - Wikipedia, the free encyclopedia
• When Solid State Drives are not that solid | Milliseconds Matter
• SSDをめぐる議論に浮かび上がるベンダ模様（1/2） － ＠IT

ネット回線の転送量を知りたくなったのでメモ。RTX1100とは書いたけど、ヤマハルータ全般で使えるハズ。

show status lan2でLAN2ポートの送受信パケット数を取得出来る。LAN2以外を外部通信に使ってるなら適宜読み替えてくだしあ。

> show status lan2
LAN2
説明:
IPアドレス:                     192.168.0.1/24
イーサネットアドレス:           XX:XX:XX:XX:XX:XX
動作モード設定:                 Auto Negotiation (100BASE-TX Full Duplex)
最大パケット長(MTU):            1500 オクテット
プロミスキャスモード:           OFF
送信パケット:                   14675823 パケット(2594214328 オクテット)
  IPv4(全体/ファストパス):      14532497 パケット / 11471073 パケット
  IPv6(全体/ファストパス):      1 パケット / 0 パケット
受信パケット:                   17463235 パケット(15242278294 オクテット)
  IPv4:                         14692144 パケット
  IPv6:                         0 パケット
未サポートパケットの受信:       2564160
受信オーバーフロー:             102

ついでに、アップタイムはshow environmentでおｋ。

> show environment
RTX1100 BootROM Rev.5.07
RTX1100 Rev.8.03.94 (Thu Dec  5 19:06:16 2013)
  main:  RTX1100 ver=c0 serial=XXXXXXXXXXX MAC-Address=YY:YY:YY:YY:YY:YY MAC-Address=ZZ:ZZ:ZZ:ZZ:ZZ:ZZ MAC-Address=WW:WW:WW:WW:WW:WW
CPU:   5%(5sec)   3%(1min)   3%(5min)    メモリ: 33% used
実行中ファームウェア: exec0  実行中設定ファイル: config0
デフォルトファームウェア: exec0  デフォルト設定ファイル: config0
起動時刻: 2015/05/15 19:47:41 +09:00
現在の時刻: 2015/06/30 16:38:14 +09:00
起動からの経過時間: 45日 20:50:33
セキュリティクラス レベル: 1, FORGET: ON, TELNET: OFF

いつ頃からから、Netatalk 3.1.7で提供しているボリュームとの接続が突然切れる現象が起きるようになった。

正確な発症条件は不明だが、ストレージの読み書き負荷が高い時や、巨大な動画ファイルでシークすると発生しやすい印象。いずれにせよ、何の前触れもなく発生し接続断のダイアログも出ないので地味にストレスが溜まる。

接続が切れる直前は決まって、ログにdsi_stream_sendかafp_read_extのCannot allocate memoryが記録されている。

Jun 02 23:55:18.897112 afpd[57517] {afp_dsi.c:624} (debug:AFPDaemon): <== Start AFP command: AFP_READ_EXT
Jun 02 23:55:18.897126 afpd[57517] {fork.c:829} (debug:AFPDaemon): afp_read(fork: 422 [data], off: 1310720, len: 65536, size: 2222591)
Jun 02 23:55:18.897156 afpd[57517] {fork.c:880} (debug:AFPDaemon): afp_read(name: "01 プロローグ・静かなる侵略.m4a", offset: 1310720, reqcount: 65536): got 65536 bytes from file
Jun 02 23:55:18.897170 afpd[57517] {dsi_read.c:29} (maxdebug:DSI): dsi_readinit: sending 65536 bytes from buffer, total size: 65536
Jun 02 23:55:18.897183 afpd[57517] {dsi_stream.c:530} (maxdebug:DSI): dsi_stream_send(65536 bytes): START
Jun 02 23:55:18.897353 afpd[57517] {dsi_stream.c:564} (error:DSI): dsi_stream_send: Cannot allocate memory
Jun 02 23:55:18.897375 afpd[57517] {fork.c:913} (error:AFPDaemon): afp_read(01 プロローグ・静かなる侵略.m4a): Cannot allocate memory
Jun 02 23:55:18.897397 afpd[57517] {dsi_stream.c:281} (maxdebug:DSI): dsi_stream_write(send: 18 bytes): START
Jun 02 23:55:18.897419 afpd[57517] {dsi_stream.c:325} (maxdebug:DSI): dsi_stream_write(send: 18 bytes): END
（中略）
Jun 02 23:55:18.898533 afpd[57517] {cnid_dbd.c:498} (debug:CNID): closing database connection for volume 'Decomo'
Jun 02 23:55:18.898578 cnid_dbd[57522] {comm.c:207} (maxdebug:CNID): comm_rcv: got data on fd 5
Jun 02 23:55:18.898980 afpd[57517] {afp_dsi.c:108} (note:AFPDaemon): AFP statistics: 3177.09 KB read, 2524196.96 KB written
Jun 02 23:55:18.899005 afpd[57517] {dircache.c:615} (info:AFPDaemon): dircache statistics: entries: 2088, lookups: 10018, hits: 7503, misses: 2463, added: 2140, removed: 52, expunged: 52, evicted: 0
Jun 02 23:55:18.899020 afpd[57517] {dsi_stream.c:530} (maxdebug:DSI): dsi_stream_send(0 bytes): START
Jun 02 23:55:18.899033 afpd[57517] {dsi_stream.c:538} (maxdebug:DSI): dsi_stream_send(16 bytes): DSI header, no data
Jun 02 23:55:18.899045 afpd[57517] {dsi_stream.c:281} (maxdebug:DSI): dsi_stream_write(send: 16 bytes): START
Jun 02 23:55:18.899068 afpd[57517] {dsi_stream.c:325} (maxdebug:DSI): dsi_stream_write(send: 16 bytes): END
Jun 02 23:55:18.899089 afpd[57517] {afp_dsi.c:137} (info:AFPDaemon): Connection terminated
Jun 02 23:55:18.899899 afpd[57498] {main.c:149} (info:AFPDaemon): child[57517]: exited 1

Mac側はOS X v10.9.5で、サーバ側はFreeBSD 10.1-RELEASE。10.1RにはZFSのARCがメモリを食いつぶすバグがあるらしく、それが原因かと思って10-STABLEに更新するも、症状は相変わらず。

で、試行錯誤を続けていたが、Netatalk 3のsendfileを有効にしたらピタッとおさまった。正確には未だ出るけど、Netatalkとの接続は維持自体はされるようになった（自動で再接続されている模様）。おぼろげな記憶をたどると「ZFS環境でApache等のsendfileを有効にするとキャッシュの二重持ちになる可能性がある」という資料を見て、sendfile無効でNetatalk 3を作り直してたような気がしないでもなく、丁度その辺から問題が出たような気がする……。

時を同じくして、同サーバのSamba 4でファイル一覧の取得がタイムアウトしたり、動画が全く再生できなくなったりしていたのだが、こちらは逆にuse sendfile = yesを無効化したら直った。

全く以て謎だ…