論理的思考力 初歩

授業や講座でも人気の論理的思考力のおはなし。最近だいぶアップデートされたので、これをChienomiでも紹介することとする。

論理とは

周辺事情から間接的に事象を確定する(観測する)ことである。

論理は“真”または“偽”で表す。成り立つものが“真”、成り立たないものが“偽”である。 「部分的に成り立つ」ということはない。成り立たないこともあるのであれば成り立つことが証明できていないからだ。 偽であることは「必ずそうでない」ことを証明するのではなく、「必ずしもそうはならない」ことを証明するものである。

よって、物事は圧倒的に偽になる可能性が高く、真であることとは本質的に同一または包括関係であることが多い。 真であるとする証明が正しくないことを証明するためには、わずか一例でも成り立たない例を示せばよい。

論理は因果関係である。「Aであるならば、Bである」というものだ。 AとB(因果)を逆にしたものを「逆」という。 つまり、「BであるならばAである」ということだ。

逆は必ずしも成り立つとは限らない。特に、AがBを包括するとき、AであるときBは十分条件を満たすため真になるが、BはAの一部でしかないためBであってもAでない場合というのが存在することになる。 もし、AとBが同一であれば逆も真となる。

AとBが共に否定関係にあるものを「裏」という。 つまり、「Aでないならば、Bではない」というものだ。

これが成り立つためには、AがBにとっての必要条件である必要がある。 AがなくてもBを満たす方法があれば裏は成り立たない。 そして、「裏が成り立つ」と「AはBにとっての必要条件である」は等しい。

なお、論理的に言う「否定」とは「論理反転」を意味する。だから、「〜ない」を否定すると「〜である」になる。

「逆」と「裏」の両方にあたるものを「対偶」という。 「Bでないとき、Aではない」である。

対偶はあまり使わない。意味としては裏を逆にしたものであり、BがAの必要条件であることを意味する。 裏も対偶も真であるのに逆は偽である、というケースはだいぶ稀だ。 互いが必要条件であるならば、両者は密接な関係にあると考えて良いからだ。 ただし、必須の包括状態にある場合には、逆だけが偽になることもある。

これは高校数学でやるのだが、高校では数学をやらないケースもあるため、知らない人もいるだろう。 私も数学ではやっていない。

余談だが、「逆に言う」「裏を返す」は、まんま論理学的用語であるため、ちゃんと逆ないし裏になっていないと、私としては教養のない人だなぁ、という感想を抱く。

論理の初歩にナンプレを

ナンプレ(ナンバープレース)というパズルがある。

かなりメジャーなもので、やったことのある人も多いだろう。 一時期、Nintendo DSがリリースされたブームになったりもした。

ルールはシンプルだ。9×9の81マスがあり、各マスには1から9の数字が入る。 ただし、制約があり、縦列、横列、及び3×3で区切られた中には重複する数字を入れてはいけない。

ルールは以上だ。

このルールの時点で論理的に解法を求められる。 ちなみにもナンプレの攻略テクニックとしてこれ以外の方法があったりするのだが、ここはあくまで普通に論理的に解くこととする。

空行の候補は1から9の数字である。 これは、ルールによって定義されており、直接的に表現されている。

そして、ルールから「縦列、横列、または区画において出現している数字は除外できる」ということが導ける。 これら出現している数字をあてはめた場合、ルールに反することになるからだ。

ごく簡単なナンプレ問題では、このように除外することで候補がひとつしか残らないマスが出現する。 マスには数字を入れなければならないため、候補がひとつになった時点でそのマスの値は確定する。 このように順次確定することでマスを埋めることができる。

そのマスだけを見たとき、直接定義されているのは「1から9の数字が入る」ということだけだ。 だが、周辺事情によってそのマスの値は確定することができる。 それが確定するのは、そのマスの値が残された候補でないとき、そのパズルのマスを埋めることができない、という命題が真になるからだ。 よって、そのマスは最後に残された候補の値にならざるを得ない。

これは、「周辺事情によって他の可能性が消去される例」である。

もう少し難しいナンプレ問題だと、複数の候補が残る。 この場合、そのマスに値を入れるとその影響によって候補が残らないマスというのが発生する。

だが、そのマスの正しい値というのはわからない。候補1になるマスは存在しない状態だ。 しかし、いずれかの候補値を仮定すると、結果的に他のマスの値が確定することになる。

このとき、マスが「答を入れることができない」状態になることがある。残される候補が0になるのだ。 これはつまり、仮定した値が間違いであることがわかる。よって、仮定したマスの候補から除外できる。

これは、「Aの値がXであるとき、ゲームBはクリアできなくなる」が真になるため、「Aの値はXではない」が成立するのである。

このように問題を一旦仮定することで、成立しなければ除外するということができる。 これもまた、「周辺事情によって偽であること良いが明らかになる例」である。 先に述べたように「AであるときBではない」の裏「AでないときBである」が成立するわけではないことに注意してほしい。 例え仮定した結果成立したとしても、それによって真であることが証明されるわけではないのだ。

実際、ナンプレでも複数の値によって仮定しても確定する値が矛盾をきたさないこともある。 実のところ、ナンプレの場合は基本的には最終的には埋められる値は1つしかない。もっとも、数多い空きマスの全マスに対して仮定を適用するのは、人間にはちょっと無理だが。 だが、現実にはそうでない場合も少なくない。想定すべき全体像がわかっているとは限らないからである。 そのため、例え直ちに矛盾をきたさないことが、その仮定が正しいことを証明するわけではない―ただし、正しいのではないか、という推測は成り立つ。

パズルと論理

ナンプレに限らず、パズルではこのような論理性を持った論理パズルが多い。 クロスワードのような潜在的に特殊な論理性を要求するものを割と珍しい。もっとも、ビデオゲーム用のパズルは全く別だが。

このような最も基本的な論理の適用方法は消去法である。 まず現在の状態から採りうる候補を列挙し、状態の変化に合わせて消去していく。 回りくどい方法だが、「こうだからきっとこうだ」などと推測するよりはずっと正確だ。

ボードゲームも、総当りすることができるのであれば、このような論理ゲームとして成立する。 実際、マルバツゲーム程度であれば論理ゲームとして成り立つ。 ただし、実際はそれが不可能であるため、別の方法をとることになる。

「らしさ」と論理

ナンプレにおいては明確に制限された規則によって論理を求めることができた。 だが、実際にはそのような状況を設定することができないことのほうが多い。そこで、逆に規則のほうを設定して、「論理が成立する条件」を求めるという手法もある。

規則は前提条件である。命題自体には含まれていなくても、その命題が設定される時点で常に適用されるものになる。 例えば、ナンプレであれば、「ナンプレのルールにおいて」という規則がある。そして、ナンプレのルールという形で様々な条件が設定されている。

規則がまるで導入されていない状態で成り立つ論理というのは「真理」だが、これはかなり限定的であり役に立たない。 (さらにいえば、真理ですらも最低限、「この宇宙における法則において」という規則が導入されている)。 そこで、有益な論理を導出するために必要な規則を探すのである。

やってみればわかるのだが、規則が限定的になればなるほど論理を成立させるのはたやすくなる。 だが、実際には「規則は適切に限定されていなければならない」のである。これは、必要以上に限定的な規則では有益ではない、ということだ。 ちなみに、導入した規則の存在を忘れてより一般性がある論理であるかのように言うのは愚か者である。

基本的には成り立たない論理というのは、それが当てはまる場合と当てはまらない場合の両方が存在するわけだが、規則のほうを限定していけばいずれ成り立つ。だが、その場合、「命題が何かを証明しているわけではなく、規則によって結果が必然的である」ということもあり、このような場合は有益ではない。

有益な論理というのは、「規則、命題ともに適切に限定されており、同じことを指してより限定的である以外に成り立たせる方法がない」というものである。 そして、論理の追求とは発見している論理や規則を、これに限りなく近づけることである。

論理では確定的事象を扱うため、確率の話は基本的にはしない。 だが、観測においては「確からしさ」というものを取り扱う。これは、確率の話である。

勘違いされがちだが、確率というのは「割合」とは違う。観測された事象のうちN%が該当するから事象の成立する確率はN%である…というほど単純な話ではないのだ。 (もちろん、この物言いがやや統計学に喧嘩を売るものであることはわかっているが、確率が統計だけのものだと思ってもらっては困る)

それが真である確率を強調していうのに、語義は同じだが「蓋然性」という言葉を使うことが多い。 「真である確率」とは基本的には「真にならざるを得ない条件」の蓄積である。

例えば、「地球には雨が降る」という事象の蓋然性について考えるとき、まず地球圏に(十分な量の)水分が存在することに着目する。 そして、地球圏の温度が均一たり得ないことを踏まえて考えると、その水分は偏りを持って移動すると考えられる。

この時点で「地球には雨が降る」を偽たらしめるのは、水分が大気中に混ざったまま浮遊していられる量である場合や、地球上に雨となりうる温度条件が存在しない場合などだ。 気象の話を本格的にし始めると多くの読者を置き去りにしてしまうのでイメージの話にとどめておくが、これら「偽の可能性」はいずれも否定しうる。

結果として、「地球上には雨が降る条件が揃っている」「地球上で雨が降らない条件は満たすことができない」ことから「地球には雨が降る」を真とみなすことができる。

しかし、物事によっては「これ以上偽たらしめる条件がない」ことを確定できない場合がある。 あるいは、偽たらしめる命題が偽であることを証明できない場合もある。 これらの不確定部分を「確かであること」から差し引いたのが、事象の確からしさ、ということになる。

なお、この節は非常に短絡的に述べているのはわかっているし、それはブログとして書けるものの制約によるものなので、論理学・天文学・量子力学・統計学・気象学できる系諸兄にはお見逃しいただきたい。

予測可能性

事象は連続する、という自然な感覚がある。 これは、自然においてそうなっているからなのだが、感覚的にはそれを拡張して捉えようとする。

これは理系文系の違いであると言われることもあるが、基本的には法則性・規則性が強いほうが予見できる、というのは事実だ。 というよりも、法則性・規則性がないものは予見できない。

このようなものを我々が強く意識するのは命名規則においてだ。 例えばメソッド名にaddElement, delElement, editElementがあったとする。 この状態でaddGroupが登場すれば、きっとdelGroupeditGroupがあるに違いないと考える。 もちろんそうであるべきで、いきなりgroupDelchangeGroupValueなんてメソッドを導入すべきではない。

似たような話だと、Unix系ユーザーアカウント操作コマンドがある。 useradd, userdel, usermodは一連のコマンドなのだが、これとは別にadduser, deluserというコマンドもある。 これらは全く別の体系にあるコマンドであり、useraddusermodとはコマンド形式からして違う。

ところが、これだけ提示されるとmoduserがある、と予見してしまう。 実際にはなく、vipwを使うのが基本であった。ところが、いくつかのLinuxディストリビューションは、adduser及びdeluserを採用した上で、usermodだけを導入する、ということをしてしまった。これだと、「変更コマンドだけ語順が逆、しかも書き方も全く違う」という事態であり、大変な混乱をもたらす。実際、これによって混乱しになっていた。ている人は多かったし、LPICでも結構な間違いポイントになっていた。

コマンド関係で言うと、serviceコマンドは引数が「サービス アクション」の順なのだが、systemctlコマンドは「アクション ユニット」の順で、このあたりも予見可能性を低下させている。

このような予見は非常に強く働く。あるワードが登場した時点で、例え法則性を提示されなくても、法則性があるのではないかと考えてそれを探す、という行動は極めてよく見られるし、検索語句としてもよく現れる。 このことから、「人は非常に強く物事に法則性を見出そうとするし、予見可能性が低いものを非常に嫌う」ことがわかる。

もうひとつよくある話だと、+=演算子の話がある。

A = A + Bを表すのにA += Bと書けるのだが、四則演算は減算(-), 乗算(*), 除算(/)もあるから、-=, *=, /=があると考えるのが自然であり、多くの人はそのように予見する。 そして、そうなっている言語も多い。

だが、実はそうなっていない言語というのも結構ある。 例えばzshは+=しかない。

この理由は、そもそもzshは四則演算がArithmetic evalutionの中でしか行われず、裸で演算子を書くことができないからだ。 そして、+=は配列に対するpostpendとしてのみ書くことができ、-=は文意が不明瞭になるため実装されていない。 実際、Arithmetic evalutionを使って(( A += 10 ))のような書くことはできる。

+=を四則演算以外に適用できるようにするケースも多い。少なくとも文字列の追加には使えることが多いし、配列の追加にも使えることが多い。 Rubyでは+メソッドが定義されてさえいれば、A += BA = A + Bとして評価させることができる。(ただし、例によってAは一度しか評価されないので同一ではない)

そのため、+=は汎用的に使える、と予見しがちである。しかし、Perlでは+=は数値演算以外に使うことができない。 そもそもPerlでは+演算子事態が数値演算に限定されており、文字列連結は.演算子を使う。 Perlは最近の大抵の言語よりも古い言語なので、Perlに責任はないのだが、今は一般に+=を一般化して使うことができるようになっているため、Perlよりも新しい言語から学び始めた人はPerlの挙動に予見可能性が低いと腹を立てることになる。

さらにいえば、+=は非常にメジャーな演算子であるため、JavaScriptに+=演算子がないことを腹立たしく思う場合もある―私はとても思うのだが、検索してもあまりそのような意見は見ないので、ひょっとしたらマイナーな意見なのかもしれない。

この予見可能性は基本的に「その人の中で成立しているように感じている論理」に基づいている。 法則性というのは観測の限りであり、別にそうなるものだという証明がなされているわけではない。だが、見出した法則性というのはその人の中では成立している論理と等しく、これに反するものは非常に強く裏切られたように感じられる。

設計におけるユーザビリティとしては予見可能性を高く保つことは何よりも優先される。 これは、APIであろうが、UIであろうが、挙動であろうが全てに言える。 予見可能性の低いUXというのは、例えばゲームで爽快感の低い操作を強いられて、ようやく動きが出てきて操作に追従するようになってきたと感じた途端に長いロードが入る、というのを繰り返すような不快さを提供することになるのだ。

そして、予見可能性を高めるということは、その枠組みの中で成立する論理を提供する、ということでもある。 例えばvipwは古くからあるコマンドだが、これは/etc/passwdファイルに変更を加える。これはユーザー情報のファイルであり、であれば/etc/groupを編集するvigrがあるはずだ…と予見する。特に、後に/etc/sudoersを編集するvisudoが追加されたことから、vi$targetという法則性を見出すことができるようになったという点も大きい。 vigrはかなり長いこと存在しなかったが、やがて追加された。これは、「ユーザーアカウントに関する編集を行うコマンドはvi$targetである」という論理性を創造した、ということになる。

自分でコントロールできる範囲であればより積極的にそうすべきである。 例えば、parmas[user]パラメータがparams[user][name]のように連想配列として提供されるのであれば、params[group]のようなパラメータが例え項目がひとつしかないとしても、params[group]によって値を返すのではなく、params[group][name]のようにすべきであるる なぜならば、そのようにすることでparams[$type][$term]が予測できるようになるからだ。 良い名前は名前だけでそれが何に属するどのようなものかを推理する余地を与える。

論理的思考

「世に論理的思考と呼ばれているものは論理とは関係ない」とよく言われるのだが、ここではちゃんと論理に基づく思考を指して論理的思考としたいと思う。

論理的思考とは「AのときBたりうるか」に基づいて判断することである、と言ってよかろうと思う。 この思考が究極まで至ることができるならば、全てを知ることができるのだが、残念ながら観測を含めそうはならない。 そして、基本的には(思考停止しない限り)時間があれば論理的思考量は増やすことができるので、時間に対してこの検討がどれだけできるか、というのが論理的思考力、ということになる。

論理的思考において、既知の箇所はスキップすることができる(もし、既知であるという判断が間違っていたとしてもスキップしてしまうのだが)ため、論理的思考力によって論理的思考量が一律に決まるわけではない。 例えば将棋やチェスにおいては、必ずしも論理的思考力に優れる者が勝利するわけではなく、定石などを知っていればある程度確定した状態からスタートできるので、大きなアドバンテージを築くことができる。

また、将棋やチェスなどにおいては基本的に時間制限があり、考えうることを全て考えて指すことができるわけでもない。 このため、単純な論理的思考力によって決着がつくわけでもなく、思考経路によって大幅に左右される。 いい経路を選択すれば論理的思考量に対して得られる結果がよりよくなる。だから、現実にはよい経路を選択できる勘のようなものも非常に重要になってくる。

論理的思考において重要なのは「期待しない」ことである。 人はなにかに期待すると、そうではない結果を否定したい、というバイアスが働く。だから、論理を歪めたがる。 「情報は情報であり、事実は事実であり、論理は論理である」ということを見失わないことが大切だ。論理に血が通う必要などない。そんなものは、言動において通わせれば良いのであって、論理を歪めるために使うものではない。

また、論理の正しさを肯定しないというのは、自分の都合の良いように事実を肯定歪めようとすることである、ということも覚えておいたほうがいいだろう。

Chienomiは結論を提供しない

Chienomiに限らず、私が書く文章において結論は提供しない、というのは私の信条である。

なぜならば、人が思考する上で有益なのは情報であって結論ではない。 情報さえあれば、人はその論理的思考力と価値観によって結論を出すこともできる。

結論が声高な文章は不快なノイズである。 もちろん、経験に導かれる結論はあってもよいのだが、そこに一般性があるとするのはノイズ以上のなにかにはなりえないだろう。 これは、当人がいかなる結論を得たか、ということとは異なる。それは単なる情報であり、意味のあるものだからだ。

そして、私の書く文章は、何らかの特定の結論に達することを期待しているわけでもない。 なぜならば、私自身が特定の結論を持っているわけではなく、あくまでその時々の判断と判断材料にあるに過ぎないから、「この文章はこういうことを結論としているのだ」と感じ取ってしまっているのであれば、それは全くあなたの気のせいである。それは、もしかしたら現代教育の被害なのかもしれないが。

文面からしか文意を導けないのは、論理的思考力の欠如だろう。 私は何かを書くときには論理的完全性にはかなり気を使っているつもりなので、あなたの論理的思考力を活用すれば、より多くの情報が得られるはずだ。 もっとも、それが有益かどうかについては保証できるものではないが。

Hy Garden Leafs (はるかシステム) システムとストレージの構成 2019

さすがに無理をさせすぎたのだろうか。 マスター系ディスクに故障が相次ぎ、縮退運用となった。

従来であれば縮退運用中はなにもできないところであるが、今回は40万円近く出費しなければ置き換えられないこともあり、長期化は避けられない。 そこで、縮退運用について柔軟性をもたせた。これは以前のディスク故障からP720導入で行ったローカルシステムとグローバルストレージの併用を強化したもので、これが功を奏した形である。

ここまでの構成変化の歴史を振り返ろう。 なお、一時期運用されたがunstableで廃止されたものは除外する。

また、セキュリティ上の理由からマウントポイント等のファイル名はフェイクはフェイクである。

構成変化の歴史

最初期

SSD 64GB + HDD 500GB*4(LUKS, LVM Mirrored, XFS)であった。

SSDはルートファイルシステムなわけだが、として64GBと少ないため余裕が全くなかった。 そこで、500*4 (LVM mirror 1TB)のディスクを/homeにマウントする方式をとった。

システムとディスクは別々にLUKSで暗号化されており、データの集約はこのときから始まっていた。

問題は、データに関しては冗長性が保たれているためディスク故障にはある程度強いのだが、それでもこのストレージがマウントできないとほぼ使うことができないということだ。初期は/varもHDDにあったのだが、問題が多かったため廃止された。

まだこの時はシンプルな構成だった。

このときから3TBの初期に至るまでは、「LUKSが突然解除できなくなる」というトラブルに見舞われ、かなりのデータを失った。

3TBの導入

SSD 128GB + HDD 3TB*8。

単純に容量を拡大したようだが、大きな変更としてLVMをやめ、Btrfsに変更した。 実際はこの構成になってからかなり長い間従来と同じ運用をしていたのだが、LVMだとディスクは偏って使われることから分散して使ってくれるBtrfsに変更した。 ミラーレッグの追加がBtrfsのほうが簡単という理由もあった…のだが、実際はBtrfsのミラーレッグ追加はうまくいかないことが多く、理屈通りにはいかなかった。

また、LUKSで突然解除できなくなるトラブルを踏まえて、LUKSからdm-crypt plain(keyfile)に変更した。

従来は/homeにマウントする方式だったが、このときから~/.localにサブボリュームをマウントするように変更した。 この名前だけはフェイクではなく、~/.localというディレクトリがシステム的に使われるようになったときに困ってしまった。

定期snapshotもこのときから始まった。

2系統へ発展

( SSD 128GB + HDD 3TB * 8 ) + (HDD 500GB + HDD 3TB * 4)

Btrfs mirroredなマスター系に加え、Btrfs singleのスレーブ系が追加された。 この時期にはもっと台数の多い構成で様々なクラスタストレージを試したのだが、結局は内蔵しておくのが一番使いやすいという結論に達した。 そのため、かなり無茶な方法でケース内に、多いときは13台ものディスクを搭載していた。

この時期に様々な理由で内蔵できない時期があり、その場合SSHFSを使っていたのだが、低速であること、変なタイミングでI/Oが詰まること、rootがファイルを扱えないことなどから「いまいちである」という結論に達している。 また、ネットワーク不調などにより暗に切断されてしまうとファイルにアクセスしようとしたプロセスが固まるという問題もある。

スレーブ系統に対してはBtrfs sendを使ってデータを転送していたのだが、Btrfs send/receiveが途中で固まってしまうという問題に遭遇し、途中からrsyncによる運用に切り替えていた。 結局、これは「ATAエラーが出るとBtrfsはファイルシステムをreadonlyにする」という挙動に起因し、ディスク不調が原因だったのだが、Btrfsがディスク不調に非常に弱く、かつ適切なレポートをしないという問題は現在に至るまで解決されていない。Btrfsが変な挙動を示したらBtrfsの言うことではなくカーネルログを確認するというのが基本的手法と化している。

同期手法はクラスタファイルシステムのミラー機能なども試したのだが、最も「シャットダウンしやすく、家庭が使うには柔軟な方法」は任意のタイミングで転送を行うことだった。

マウントポイントは~/globalに変更された。

NAS導入

( SSD 256GB + HDD 3TB * N1 + HDD 3TB * N2…) : (x + HDD 4TB * N1 + HDD 4TB * N2…)

ホスト数1では対応しきれなくなったことから、複数ホストでストレージを構成することになった。 これに伴って、従来は中核ホストが全ブロックデバイスをまとめてBtrfsにしていたのだが、この構成となってから各ストレージターゲットは自身で「暗号化され、冗長化されたiSCSターゲットを提供する」という方式に変更された。暗号化処理がホストに分散されるようになったため、少し軽くなった。

また、基本的にはストレージをRAID5で提供するということにしたので、容量が稼ぎやすくもなった。非常に大きくなったディスクをカバーするため、ディスク単位以外にユニット単位での置き換えも可能になった。これは、イニシエータホストから見れば1ユニット(ホスト)で1台のディスクに見えるからだ。

一方、Btrfs RAIDはmeta mirror, data singleに変更した。これは、data mirrorであっても復元があまり現実味がないという事実を踏まえてのことだ。 実際に最もうまくいったケースですら、btrfs balanceの最中にディスクが故障して失敗したし、btrfs balanceは非常に時間がかかる。 もちろん、scrubによる修復も効かなくなるのだが、scrubで修復するようなケースで問題が解消したことがないので、素直に下層のRAIDに任せたほうがうまくいくという結論に達したのだ。

つまり、

  • ターゲットは冗長性とセキュリティ(ディスクの暗号化)を保証する
  • イニシエータはネットワーク経由で提供されるブロックデバイス(普通はiSCSI。AOEだと問題が出るケースがある)をBtrfsデバイスとしてmeta mirror. data singleで編成する

というルールである。

SSDが256GBになったこともあり、ある程度データをSSDに置くことができるようになった。 そこで、新たに~/intを追加し、ここに運用に必要なデータを置くように変更した。

この変更はかなり大きい。従来の方式だとグローバルストレージがマウントできない状態だと何もできない。 そもそも、XDGディレクトリがシンボリックリンクであり、そのポイント先がグローバルストレージにある場合、マウントしない状態でログインするとXDGユーザーディレクトリの設定自体がリセットされてしまう。 また、Clutter launcher(Cinnamonのアプレットとして標準のアイコンランチャ)は.desktopファイル自体が有効でない場合はlauncherの設定自体を破棄してしまうし、.desktopファイルで指定されたコマンドが実行できない場合はランチャから一時的に除外する。

このことから、~/intには日常的に作業で利用するXDG DOCUMENTSディレクトリ、~/binディレクトリ、自分のリポジトリ(~/devel)、フォント(~/.fonts)をはじめとするリソースファイル、ブラウザプロファイル1、メール(~/Mail)などが含まれている。

つまり、~/intがあることによってログインに支障が出たり、基本的な作業すらできなくなるという問題が解消され、ほとんどのデータにはアクセスできないが最低限ログインして作業はできる状態が保たれるようになった。

実はこのことはかなり大きく、グローバルストレージになんらかの問題が発生し、データにアクセスできない状況が発生するのは全く珍しいことではなかった。その間本当に「なにもできない」状態になっていたのだが、これを解消したのである。

果たしてその状況は現実に訪れた。複数ディスク故障により縮退運用に至り、これが長期化する見通しとなったが、もしこの作業をしていなかったらまるで仕事にならない状態が継続していたことになる。

Btrfs RAID5について

結論から言えば使い物にならない。

現状、Btrfs RAID5はbtrfs device replaceがうまくいく保証がない。btrfs device removeに関してはほぼうまくいかない。 完全にexperimentalである。

では気休め程度に使えるかというと、そんなことは全く無くて、Godavariマシン(A10-7870K)ではCPUが100%に張り付き、極めて不安定なI/Oを見せる。 連続で転送していると調子がいいときは2時間で200GB程度を転送できるが、調子が悪いときは17時間で20GBしか転送できない。 これは 書き込みだけでなく、読み込みでも発生する

ダメだ、ダメだと言っているばかりで誰も実用しないので実態がわからないから勇者になってみたのだが、まぁ、ひどい。

AOEとBtrfsについて

詳細はよくわからないのだが、まずAOEでmkfs.btrfsしたBtrfsボリュームはローカルにはマウントできないし、逆にローカルでmkfs.btrfsしたBtrfsボリュームはAOE経由ではマウントできない。

だけならいいのだが、マシンに複数あるブロックデバイスをAOEデバイスとして登録し、これをそれぞれAOEデバイスにした場合、そのBtrfsは再起動後マウント不能になる。


  1. 私は自作の、ブラウザプロファイルを選択した状態で起動できるプログラムを使用しているため、多数のブラウザプロファイルがある。