start

空き容量0でZFSが壊れた?Input/Output errorが発生→再起動で直った

不注意で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%1)を切ると危険水域とされている。予めプール全体にquotaをかけておけば、今回のようなヤベェ自体は予防できるだろう。


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

FreeBSDのSambaのビルドでncurses not availableが出てた

家鯖のFreeBSDのnet/samba413をビルドしようとすると、configureでncursesが見つからんと言われてコケるようになっていた。

ncurses not available, cannot build regedit
ncurses not available, but --with-regedit was specified

ncursesってbaseに含まれてたような…なんでエラーになんの?と思いつつ、念のためdevel/ncursesを入れても効果なし。Sambaの依存パッケージじゃないし、そりゃそうだ。

portsのバグを疑いしばらく放置&再試行してみたものの、一向に直る気配がない。そもそもエラーでググってもそれらしい結果が出てこないので、自分の環境の問題なのだろう。

では、どうやってシステムのncursesを直すか?

base.txzあたりでシステムを上書きすれば良さそうではあるものの、ncursesがどのtarballに含まれているのかが分からない。かといって、なんも考えずにtxz一式を展開した結果、設定ファイルなどがデフォルトに戻るのは避けたい。

そんな感じでモニョってたんだけど、たまたま目にしたFreeBSD-SA-00:68.ncursesに解決策があった。/usr/src/lib/libncursesでmake installするだけで良かったのだ。

# cd /usr/src/lib/libncurses
# make && make install

そしてSamba 4.13が無事ビルドできて一件落着。

# portmaster net/samba413

システムを飛ばしたときの復旧が不十分だったんだろうなぁ、たぶん。近いうちにbuildworldしとくか…

デュアルXeon E5 v3からシングルE5 v4にして30W削減

消費電力削減のためメインPCと家鯖を仮想化で統合してから半年、当初の目論見ほどには電気代が安くなっていない今日この頃、皆さんいかがお過ごしでしょうか。

消費電力が下がらないことに業を煮やした私は、更なる節電のためにX10DRiとデュアルXeon E5-2673v3の組み合わせから、X10SRL-FとシングルXeon E5-2680v4に変更するという暴挙に出ました。CPU1個分のベース電力が削減できるだろう、Broadwell-EPのHWP (Hardware P-states)でv3より省エネだろうという皮算用をもとに…。

(2022-01-11 追記)

壮大な勘違いをしていた。Broadwell-EPで追加されたのは、HWPM (HardWare controlled Power Management)であって、HWPとは別物だった。一応、HWPの初期実装は入ってるようだが、一部機能がなくintel_pstateドライバはHWPを使わないっぽい。

ついでに、タイトルの30W削減というのは、cpupowerで性能バイアスを15(最も省エネ)とした時の最大値で、ここまでやると操作感が明らかにもたつく。現実的には15~20W程度の削減という具合。

X10DRiにE5 v4を1つだけ載せればいいのでは?と思われるかもしれないが、PCIeスロット数の関係で叶わぬ願いだったのさ。X10世代のデュアルソケットマザーにはPCIeスロットが6本載っているものの、ソケット毎に3本ずつという割り当てで、しかもCPU1側はPCIe x16が1本のうえGPUを差すと直下のPCIe x8が隠れて実質2本しか使えない極悪配置なのである。

どうせマザボも変えるならWindows 11を見据えてSkylake-SPにしてしまうのも手だったけど、多コアのやつはまだちょーっち高いなぁって。

そういうわけで、メインマシン兼鯖の構成と消費電力は下表のようになった。

変更前 変更後
M/B X10DRi X10SRL
CPU1 Xeon E5-2673v3 Xeon E5-2680v4
CPU2 Xeon E5-2673v3 -
RAM DDR4 RDIMM 32GB × 6
GPU GeForce GTX 1650 D6
NIC ConnectX-3 EN Pro
PCIe USB 3.2 (ASM3142)
PM963 1.92TB × 2
HDD ST10000NM0096 × 5
MAL38000NS-T72
アイドル時
消費電力
130W 105W

25W程度の削減となったが、100W切りは達成ならず。瞬間値なら98W程度を確認するも、まぁ殆どの場合100~105Wをうろうろしてる感じ。

DDR4メモリの消費電力は8GBあたり3W程度ということで、DDR4 RDIMM 32GB×2枚を取り外して24Wの節約だぜ!?と試してみたら、せいぜい5W程度しか変わらなかった…。それも明確に下がったわけではなく、なんとなーく下振れしてるかなー?という程度。10W削れるならともかく、これならメモリ+64GBの恩恵を受けた方がいいかなと。

これ以上の消費電力削減は無理な予感だなー。CPUやメモリの電圧弄れば違うだろうけど、お堅いM/Bなので設定できるはずもなく。HDDが5W/台で6台載ってるのが最大のネックなんだよなー。

X10SRL-FのPCIe x16スロットは、マニュアル上はx8動作ということになっているが、BIOSの設定でx16動作に変更することができた。この場合、同じPCIeリンクを共有するPCIe x8スロットは当然だけど使えなくなる。PCIeバイファケーションの設定が全パターン(x16, x8x8, x8x4x4, x4x4x8, x4x4x4x4)選べるのは、さすがSupermicroといった感じ。

マルイチセーリングの3人掛けソファ「マンスリー」を購入

マルイチセーリングのリクライニングソファー、マンスリーを買った。

決め手は何といっても座り心地。適度な沈み込みと反発のある座面、腰から背中にかけてのフィット感、ヘッドレストの角度まで調整可能な座席ごとに独立したリクライニングなど、快適さに直結する部分が他のソファより頭一つ飛びぬけていた。販売員曰く「座り心地に全振りしたソファ」とのことで、座ってみればそれも納得といったところ。身もふたもない言い方をすれば、映画館のプレミアムシートの座り心地である。

(生活感あふれる写真でごめんなさいね。)

そこそこの大物のため、部屋に入れたら威圧感かなり出るかな~と懸念していたが、いざ現物が来てみたらそこまででもなかった。サイズ感と和らげるべく布地にしたのが功を奏した。

展示品はビビッドなオレンジのソフトレザー仕様で、大きさ、色、トゥルトゥルの質感が相まって、いかつさMAXなのよね。メーカー標準仕様っぽいんだけど、あの見た目で販売機会を逸してるような気がしてならない。どうしてあんな超絶人を選ぶ色をチョイスしてるんだ…。

マンスリーは家具店向けのシリーズらしく、マルイチの公式サイトには載っていない。基本仕様は同じで、店ごとに細部が微妙に異なるシリーズとして展開しているようで、マンスリー、ウィークリー、コーラス2といったブランドがある模様。関東だと、マンスリーはかねたやが、ウィークリーは島忠が扱っている(2021年8月現在)。

そもそもこのソファとは、かねたや主催の家具バザールで出会い、その後、近所の島忠でたまたまウィークリーを見つけたという次第。基本的な座り心地は一緒だったが、ウィークリーの方が僅かに座面が柔らかく、そのためか座高自体が少し低いように感じられた。寸法はどちらも同じらしいんですけどね、中のウレタンが微妙に違うらしい。ほかにも確認できた限りでは、脚の形状、追加オプションに差があった。

その辺を諸々考慮し、何より座り心地的にマンスリーの方が好みだったので、マンスリーに決定!

座席数と席幅からベースとなるモデルを選び、表面仕上げ(本革/合皮/布地、色柄)とオプションにより最終的な仕様と値段が決まる。当方は540ソファ(54cm幅の3人掛け)を選択し、ネコチャンがいるので、布地の中でもペット向けを謳う引っ掻きに強いものにした。色は冒頭写真の通り、、、灰色?ベージュ?砂色?。素材によって選べる色に差がある点は留意されたし。

お値段は20万円代前半也。決して安くはないが、べらぼうに高いわけでもない…と思う。

正直、若干の予算オーバーではあるが、展示会でピンからキリまでいろいろ座ってみた中で、自分に合ったソファがたまたまこの値段だったという感じ。安い物はやっぱりそれなりの座り心地でしかなかったし、逆に高いからといって必ずしもフィットするわけでもなく、手の届く範囲で良いものが買えたと思うことにする。将来、たとえソファ自体が廃番になっても、会社が無くならない限り修理や張替え対応はしてくれるそうで、末永く活躍してくれることでしょう。

3人掛けはデカすぎィって人には、1人掛け、2人掛けモデルもあるよ!

ちなみに、以前はルームズ大正堂のフランドルソファを使っていた。13年ほど使ったが、ソフトレザーのわずかなくたびれと退色くらいのもので、クッション・ばねに目立った劣化や、構造的なガタはなかった。最後の半年の間にネコチャンにつけられた引っかき傷が一番の傷という。ソファ買い替えの無料引き取りで処分予定だったが、ジモ○ィで引き取り手が見つかり、今頃そちらで活躍してくれていることだろう。SDGs!

OpenZFSにRAIDZ Expansionのプルリクができてた

今まで気づかなかったが、2か月ほど前の6/11に、待望のRAIDZ ExpansionのプルリクがOpenZFSに立てられていた!!2018年のプリアルファコード以来目立った動きがなく、どうなっとんじゃーいって感じだったが、June 2021 FreeBSD Developer Summitでの報告の翌日、PRが作られた模様。

コードレビューは始まったばかり、というかまだ進んでない?ようでリリースはまだまだ先っぽい。OpenZFSプロジェクトの状況としては、現在は2.1リリース作業の真っただ中で、取り込まれるのはどんなに早くとも来年リリースのOpenZFS 2.2あたりと見込まれている。まぁ、かなり大きい変更なのでレビューもテストも時間がかかるだろうしね、仕方ないね。

PRの議論を見るに、拡張時の挙動である「既存データのストライプサイズは変更しない=データ/パリティ比率は変わらない」という点が、結構引っかかってるっぽい雰囲気。

RAIDZ ExpansionでRAIDZ vdevにストレージを追加した場合、vdevの物理ストライプ幅は拡張後のサイズとなる。対する論理ストライプ幅については、既存のデータは拡張前の幅、再書き込みを含む新規データは拡張後の幅となる。具体的な数値を当てはめると、HDD 5本のRAIDZ2プールをHDD 6本に拡張した場合、既存データは論理5ストライプ(データ/パリティ比=3:2)のままで、新規データは論理6ストライプ(データ/パリティ比=4:2)で記録される。データによってストライプ幅が異なること自体は、RAIDZの元からの仕様なので問題ないらしい。

一方で、この仕様のため既存RAIDZプールの使用率が高いほど、RAIDZ Expansionでのプール拡張後の実効空き容量は増えにくくなる。例えば、1TB×4のRAIDZ1プールに1TB書き込むとプール使用率は33%なのに対し、1TB×3のRAIDZ1プールに1TB書き込んだあと(この時点での使用率は66%)で1TBのHDDを追加しても使用率は66%のままとなる。既存データのデータ/パリティ比が変わらない以上、この容量オーバーヘッドは避けられない。

RAIDZ ExpansionでRAIDZプールは何度でも拡張可能だが、こんな感じゆえに、最小構成で始めて必要に応じて後からディスクを追加する、という戦略は取りにくいのは否めない。

使っていく中で既存データも新しいストライプ幅に置き換わり、このオーバーヘッドは徐々に解消されていく。このあたりの挙動は他のプロパティと一緒で、ZFSの思想っぽいというかなんというか。可及的速やかにプール容量を最大効率で増やしたい!という場合には厳しいだろうが、現実的にそんなケースがどれだけあるのだろうか?そもそもZFS的にはそんなカツカツ運用するなよって感じ?

拡張時に全データの再配置を行ってるにもかかわらず、既存データの論理ストライプ幅を変えないは、実装の簡便さと拡張中のRAIDZ1/2/3の冗長性担保が理由とのこと。

このまま無事マージされて欲しい。

  • start.txt
  • 最終更新: 2019-08-19 11:45
  • by Decomo