2022年、クソゲ〜製作所は「のふ処」に変わります(ました)

謹啓　初春のみぎり、いよいよご壮健の由、大慶に存じ上げます。

さて、日頃ご愛顧賜っております弊サイトは、2022年元日を以てクソゲ〜製作所から「のふ処」(のふどころ)に改名することとなりました。併せてドメインもnofu.jpに変わります。中身、コンテンツ、運営方針については従前通りで変更はありません。

要はただのサイト名とドメイン名の変更ですな。理由は以下の通り。

SEO、検索性の問題
ドメインが汚れてきた
地域性の明確化とドメイン名の短縮

decomo.infoは自分の名字と某大手携帯キャリアをもじって付けたものだけど、今となってはSEO的に非常に不利となっている。decomoで検索しても、あっちがサジェストされちゃうんだもの…大企業だしそれこそ重要なインフラを担ってらっしゃるので当然なんですけどね。「クソゲ〜製作所」という名前も同様で、長音符がわりの「〜」は検索エンジンと相性が悪いっぽい。意味のある単語として認識されてないような挙動。波ダッシュ問題も影響してる気がして、非常によろしくない。

この名前は、ゲームプログラマを夢見た高校生の時代に「クソゲ〜製作所というブランドで面白いゲームを作ったら楽しいじゃん」という安直さと、クソゲーは作らないという少しの矜持を込めて付けたものだ。

それから幾年、曲がりなりにも夢は叶い、誰もが知る某有名タイトルなんかにも携わることができたが、ついぞ自分でゲームを作ることはなかった。実のところゲーム業界を離れて既に4年が経つし、ゲームという看板の降ろしどきかなと。

とはいうものの、「のふ処」の“のふ”はクソゲ〜のクを「ク→ノフ→のふ」と変化させ、“処”は製作所の「所」から来ているので全く無関係というわけではない。よりストレートな案として、当初はクソ所（くそじょ/くそどころ）もあったが、いろんな意味で直球過ぎてボツにした。個人的には嫌いではないけど、流石にメールアドレスとして公衆送信するのは憚られるのでｗ

メールアドレスの点では、decomo.infoだと冒頭の有名企業の兼ね合いでバッタもの感が強いし、20年も使ってると情報漏洩やら何やらで汚れて来るんですわ。そうなんですよ、decomo.infoは2002年3月27日に取得してるんで、今年で20年なんですよね。ちょっとビックリですよね。

そんなわけで丁度いい節目でもあるので、4文字と短く、日本発信ってのが明確で、字面と語感が何となく良いnofu.jpに移行する。

これ自体も2018年頃から考えていたもので、実際ドメインはその時に取得済み。移行作業は遅々と進まず、むしろ面倒で進める気もなかったのが実情だが、この正月休みでやっちゃおうと、ふと思い立ったが吉日ってなもんで。ついでにページのスタイルも昨今のレスポンシブな感じに。

本年もよろしくお願いいたします。

permalink · 2022-01-01 00:00 · Decomo · 0 Comments · Tags:

PCIe 4.0なNVMe SSD、Samsung PM9A3 1.92TB (MZ1L21T9HCLS-00A07)が某所で2万円ちょいで売られていた。読み書き量が1520465GB≒1.5ペタバイトという代物で、相当にアレなブツではあるものの、 2TBのPCIe Gen4のNVMe SSDとしてはかなりの安値。PM9A3はエンタープライズ向けのSSDで1DWPDで5年の耐久性が謳われており、換算すると3504TBWとなる。仕様上の寿命は半分以上残っていることになるし、PS5用にちょうどいいんじゃね？ってことで買っちゃった。

お決まりのS.M.A.R.T.情報とベンチマーク結果。

読み書き量のわりに起動回数と時間が極端に少ない。耐久検査に使われたブツの流○品とか？1.5PBで残寿命88%ってことは、理論上は12.5PB書き込めることになる。

ベンチはPCIe 3.0接続であることに注意。うちにはまだPCIe 4.0なPCは無いのだ。

CrystalDiskMark

プロファイル

結果

デフォルト

------------------------------------------------------------------------------
CrystalDiskMark 8.0.4 x64 (C) 2007-2021 hiyohiyo
                                  Crystal Dew World: https://crystalmark.info/
------------------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

[Read]
  SEQ    1MiB (Q=  8, T= 1):  3443.566 MB/s [   3284.0 IOPS] <  2433.85 us>
  SEQ    1MiB (Q=  1, T= 1):  2542.130 MB/s [   2424.4 IOPS] <   412.00 us>
  RND    4KiB (Q= 32, T= 1):   813.802 MB/s [ 198682.1 IOPS] <   155.75 us>
  RND    4KiB (Q=  1, T= 1):    57.317 MB/s [  13993.4 IOPS] <    71.17 us>

[Write]
  SEQ    1MiB (Q=  8, T= 1):  2091.937 MB/s [   1995.0 IOPS] <  3900.20 us>
  SEQ    1MiB (Q=  1, T= 1):  1936.994 MB/s [   1847.3 IOPS] <   539.93 us>
  RND    4KiB (Q= 32, T= 1):   471.135 MB/s [ 115023.2 IOPS] <   268.97 us>
  RND    4KiB (Q=  1, T= 1):   176.707 MB/s [  43141.4 IOPS] <    21.27 us>

Profile: Default
   Test: 1 GiB (x5) [D: 0% (0/1788GiB)]
   Mode: [Admin]
   Time: Measure 5 sec / Interval 5 sec 
   Date: 2021/12/13 21:20:40
     OS: Windows Server 2016 Server Standard (full installation) [10.0 Build 14393] (x64)
Comment: SAMSUNG PM9A3 1.92TB (PCIe 3.0/M.2/Default)

NVMe SSD

-----------------------------------------------------------------------------
CrystalDiskMark 8.0.4 x64 (C) 2007-2021 hiyohiyo
                                  Crystal Dew World: https://crystalmark.info/
------------------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

[Read]
  SEQ    1MiB (Q=  8, T= 1):  3466.937 MB/s [   3306.3 IOPS] <  2417.09 us>
  SEQ  128KiB (Q= 32, T= 1):  3523.463 MB/s [  26881.9 IOPS] <  1189.22 us>
  RND    4KiB (Q= 32, T=16):  2202.203 MB/s [ 537647.2 IOPS] <   656.41 us>
  RND    4KiB (Q=  1, T= 1):    55.227 MB/s [  13483.2 IOPS] <    73.86 us>

[Write]
  SEQ    1MiB (Q=  8, T= 1):  2102.285 MB/s [   2004.9 IOPS] <  3944.41 us>
  SEQ  128KiB (Q= 32, T= 1):  2128.834 MB/s [  16241.7 IOPS] <  1963.64 us>
  RND    4KiB (Q= 32, T=16):  1609.719 MB/s [ 392997.8 IOPS] <  1070.17 us>
  RND    4KiB (Q=  1, T= 1):   121.218 MB/s [  29594.2 IOPS] <    33.34 us>

Profile: Default
   Test: 1 GiB (x5) [D: 0% (0/1788GiB)]
   Mode: [Admin]
   Time: Measure 5 sec / Interval 5 sec 
   Date: 2021/12/13 21:03:31
     OS: Windows Server 2016 Server Standard (full installation) [10.0 Build 14393] (x64)
Comment: SAMSUNG PM9A3 1.92TB (PCIe 3.0/M.2/NVMe SSD)

ATTO Disk Benchmark
MB/s	IOPS

なお、ベンチ中はS.M.A.R.T.読みで80℃近くまで上がることを確認。それなりに冷却に気を使った方が良さそう。

で、肝心のPS5はというと、使えませんでした＼(＾o＾)／

電源を入れると画面は真っ暗のままで、光学ドライブがガチャガチャ鳴る→鎮まる→鳴る→鎮まる…という状態を延々と繰り返す。状況的に途中でリセットがかかって再起動を繰り返してるような感じ。

別のPCIe 3.0なSSDで試すと「拡張スロットに装着されたM.2 SSDは使用できません。」の画面がちゃんと出たので、PS5本体は正常、何らかの理由でPM9A3が使えないっぽい。残念賞。

この微妙なPM9A3の処遇はどうしようかな…。

（2022-02-21 追記）

PS5で使えないのは、PS5のM.2スロットの電流供給能力の問題っぽい？下表は各SSDの電流値をまとめたもの。値は手元の現物SSDやネット上の画像から拾った。

SSD	電圧/電流	使用可否	備考
PM9A3 1.92TB	3.3V / 4.3A	×	起動せず
PM9A1 2TB	3.3V / 2.8A	○	使えてるっぽい
980 PRO 2TB	3.3V / 2.9A	○
FireCuda 530 4TB	3.3V / 3.0A	○
FireCuda 530 2TB	3.3V / 2.9A	○
PG4VNZ 2TB	？	○
PG3VNF 1TB	？	○
SN700 250GB	3.3V / 2.8A	△	PCIe 3.0なので使えないが起動はする

こうしてみると、PM9A3が頭一つ飛びぬけているのが分かる。

M.2規格上の定義は探し出せなかったが、何となく最大電力は10W、3.3Vで3Aあたりが上限っぽいように見える。PM9A3に電力制限かければ動くかもしれないけど、突入電流の問題のような気もする。ごついコンデンサ7個（刻印見る限り47μF？）を除去すればワンチャンあるかも？知らんけど。

permalink · 2021-12-27 04:57 · Decomo · 0 Comments · Tags:

Supermicroのマザーボードでファンの回転数をIPMI経由で制御するには、以下のコマンドを投げつければよい。

# 制御モードをFullにする
ipmitool raw 0x30 0x45 0x01 0x01

# "system"ゾーンの回転数を37.5%にする
ipmitool raw 0x30 0x70 0x66 0x01 0x00 0x24

# "peripheral"ゾーンの回転数を25%にする
ipmitool raw 0x30 0x70 0x66 0x01 0x01 0x16

まず、ファンの制御モードを“Full”にする必要がある。他のモード（Optimalとか）だと、その設定の方が優先されるとのこと。その後、ゾーン毎に回転数を設定してやる。

2～3つ目のipmitoolで送っているバイト列のうち、最後がファンのデューティー比、後ろから2番目がゾーン番号を表す。ゾーンのsystemとperipheralは、マザボのFAN用コネクタFan1系列とFanA系列に対応していると思われるが確認したわけではないので間違ってるかも。

デューティー比は0x00～0x64の64ステップとされている。でも、16進数なんだから0～100なんじゃないの？という気が…ま、ともかく0x00が最小で0x64がフル回転だそうなので、こまけぇこたぁいいんだよ！

実際のところ、Optimalで割とイイ感じに制御してくれるんだけど、ファンによってはデューティー比低すぎて止まっちゃうことがあるんですよね。で、ファン停止エラーが検出される→フル運転→エラーが止まる→デューティー比下がる→ファンが止まる→…の無限ループになるという。

この場合ipmitool sensor threshで最低回転数のスレッショルドを調整するのが定石。うちでは設定値が悪いのか、上手く動いた試しがない。

ファン制御やスレッショルドを弄ってにっちもさっちも行かなくなったら、ipmitool mc reset coldでBMCをリセットしてやればおｋ。

permalink · 2021-12-10 20:16 · Decomo · 0 Comments · Tags:

SSL証明書の期限が切れた状態でcertbot renewを行うと、ApacheプロセスのCPU利用率が100%となりハング状態になるっぽい。apachectlで止めようとしても（弊鯖はご存じのとおりFreeBSDなのでservice apache24 stopだが）、応答が返ってこずkillせざるを得ないという状況。環境は以下のとおり。

FreeBSD 13.0-RELEASE-p4
Apache 2.4.51
certbot 1.21.0
certbot-apache 1.21.0
Python 3.8.12
webrootモードで運用

weekly_certbot_enableでもって週次で証明書の確認＆更新が行われるはずなのに、なんで切れてるの？そもそも期限切れになったからと言って、なんでhttpdがハング状態になるの？と疑問は尽きないのだが、ひとまず脇に置いといて、この状況に陥ったらcertbot certonlyを使って手動で証明書を更新してやる。

# certbot certonly --webroot -w /path/to/document_root -d example.com

証明書更新後、certbot renewでhttpdが暴走しないことを確認する（renewが正常に終われば暴走はしてない。）

それにしても原因は何なんだろうなー。以前、同様の状況が発生した時は、apacheやモジュールの更新を行っていたのでバイナリ間の何らかの不整合くらいで流したが、たぶん今回と同じ原因だったんだろう。さらにその以前は正しく動いていたような気がしなくもない（結構期限切れをやらかしていたので確証が持てない）ので、よくわかりません。

詳しい方教えてください。

(2021-12-24 追記)

確証はないけど、証明書更新後にapache reloadをしておらず、新しい証明書がapacheに認識されてないのが原因な気がする。

FreeBSDフォーラムの投稿のように、証明書更新後のフックスクリプトでリロードしてやれば解決しそうな気がする。

/usr/local/etc/letsencrypt/renewal-hooks/deploy/reload_apache24.sh

#!/bin/sh
service `echo $0|sed -e 's/.*\/\(.*\)_\(.*\).sh/\2 \1/'`

パッと見「なんじゃこりゃ？」ってシェルスクだが、自身のファイル名をsedで切り出しservice apache24 reloadを実行するという、実に巧妙な仕組みだ。引用元のフォーラムでは、同様にdovecotやpostfixの証明書更新も行っていた。中身同じでファイル名を変えればいいだけとは、よく思いつくものだ。

permalink · 2021-12-01 21:02 · Decomo · 0 Comments · Tags:

不注意でProxmox VEのZFSプールを使い切り、空き容量がゼロという状態になってしまった。すべてのデータセットのAVAILが0という本物のゼロである。VMのディスクがthinで図らずもオーバーコミット状態となっており、VM内で物理容量以上のファイルコピーを行ってしまったのが原因。当然ながらVMは固まるわ、PVEもWebコンソールから何もできないわで超焦った…。

幸い物理コンソールは生きていたので、不要なZVOLを消して事なきを得たと思いきや、ファイル操作をするとInput/output errorが起きるようになってしまった。

root@myserver:/etc/pve/nodes/myserver/qemu-server# touch test
touch: cannot touch 'test': Input/output error

ファイル/ディレクトリの作成、削除がダメ。既存ファイルの読み込みは問題なさそうで、書き込み系がダメっぽい。それもすべての場所でダメというわけではなく、ルートディレクトリ直下は大丈夫だったりする。同じデータセットなのに。

もちろんzpool scrubでエラーが出ないことは確認済み。というわけで実に厄介というかヤバい状況なのであーる。どうすんのこれ…

関係しそうなバグチケ報告もあるにはある。

が、ほとんど関係ない気がしなくもない。うちはサイレントじゃないし。実は静かに壊れてて今回ので発現した可能性もあるが、ほんの数日前にVM追加してるしちょっと考えにくい。FreeBSDの方では何だかんだ10年ほどZFSを使っているが、データが壊れたのはそれなりに原因が分かっている2回しかない（1回目、2回目）。

容量ゼロをトリガーにLinux側とZFS側で何らかの齟齬が発生し、容量の回復がLinux側に伝わってないとかが原因なら再起動で直りそうなものの、シャットダウンしたが最後、完全に壊れてPVEが立ち上がらなくなる可能性もありそうで恐ろしい。この記事も書いているメイン環境は、そのPVE上で動いているのでPVEの死＝メイン環境の死なので慎重にならざるを得ない。

(2021-11-24 追記)

意を決してPVEマシンを再起動してみたら、Input/output errorは出なくなった。何事もなかったようにVMも動いている。

ZFSではCoWの関係上、一般的に空き容量がプール容量の10～20%¹⁾を切ると危険水域とされている。予めプール全体にquotaをかけておけば、今回のようなヤベェ自体は予防できるだろう。

¹⁾

昨今の2桁テラバイト級のプールなら5%程度でも良さそうだが

permalink · 2021-11-20 03:36 · Decomo · 0 Comments · Tags: