オカンが亡くなってからというもの。。。オカンを偲ぶ時間が取れず。あのときからある意味時間が止まっている。オカンの最期は、バイオリズムがとても悪い日だと想定して、その期間は休みにしていた。訪看の人は、満月の日ではないかと。実際、容態が急変したのは、偶然、11月の満月の日だった。Beaver Moonといういうらしい。まして、その日が12時間も格闘をするとは全く思っておらず、自分としては不意打ちだった。オカンの緩和ケアは11月の頭から始めたので、来年（2024年）の2月くらいまではもつのではと思ってセットアップを始めていたのだが。本来だったら、自分が1週間ほど海外へ行かなければならかったので、その間入院をする手筈を整えていたのだが。
結果としては、坂本龍一の曲のFull Moonという曲の歌詞の通り、永久とか完全ということはない。
人生であと何回満月をみるのだろうか？
ITの世界で言えば、想定はあくまでも想定でしかなく、「想定をしていない」ことが想定となり、物事を決めることがが多い。その一つがパーティションの切り方とサイズだったりする。
実際、パーティション、特に/tmpがパンクした場合、パーティションを設計した人間が咎められることがあるとしたら。。。正しく、「想定すらしていない」想定の被害者で、その当事者もそれでサラリーを得ている。
閑話休題
Linuxのパーティションの切り方は、用途によって本当にまちまち。単純に動かすだけ、利便性だけでいったら/boot以外のパーティションを切る必要はない。パーティションを切っていないがゆえに、どこかのパーティションがパンクすることもない。/(root)一つでやりくりできてしまう。
一方、セキュリティや安定稼働を考えるとパーティションは切っておくべき。例えば、/tmpパーティションが作られていない場合、/tmpの一時的容量増加が/(root)を圧迫してシステム停止になる。/tmpパーティションが作られている場合は、/tmpの一時的容量増加が起きても/(root)を圧迫することはない。
以下、ざっくり、パーティションをきるかどうかを踏まえたパーティションの解説
基本的な考え方は
- バックアップが必要かどうか？
- 書き込みがある
の２つのカットで検討する。
/boot：これは、起動用のカーネルやinitrdが入っているところなので、パーティションを切る、切らない以前に分けておくところ
/(root)：これはOS本体
/usr/local：パッケージ管理システムからではなく、tar ballや手動でアプリケーションを入れるときに使う場所。ここは、ユーザが導入したアプリケーションデータとなるのでバックアップが必要。また、このパーティションは、アプリケーションのインストールをする時以外では、読み取り専用でマウントしても動作できるようにしておくべき。
/opt：/usr/localと似ているが3rdパーティーのアプリケーションが使う場所。/usr/localに準ずる。
/home：ユーザデータが入るところ。バックアップも必要だし、書き込みが頻繁に起きる
/tmp：一時ディレクトリで書き込みが行われる。このディレクトリはいろいろなアプリが使うので独立したパーティションにするべき。またOSによっては、再起動後すると中身が空になる。
/var：ログやロックファイルが作成されるディレクトリ。ログが肥大しても影響を受けないように、独立したパーティションにするべき。
というようになる。
さて、ここからが本題だが、パーティションの容量が足らない場合、もう終わり？パーティションの再作成か、LVMだったら容量拡張をする必要があるのだが、それができない場合、「bind mount」で乗り切れるかもしれない。
bind mountとは
bind mountは、ディレクトリを「マウント」してくれる機能。
例えば
/dataというフォルダに/home/testdirというフォルダをマウントできる。
/dataの中身は、/home/testdirになる。また、もともとのフォルダにあったI/Oは、そのまま維持され、bind mountしたあとに発生したI/Oは、bind mount先に振り分けられる。つまり、仕掛かり中のI/Oには影響しない。
bind mountの使い方
mount -o bind /source /mount
/mountに/sourceディレクトリがマウントされるようになる。
bind mountの検証
/home/test1と/home/test2というディレクトリを作り、以下のスクリプトで/home/test1/test1.txtというファイルで日付を出力してみる。
#!/bin/bash
output_file="./test1/test1.txt"
while true; do
current_time=$(date)
echo "$current_time"
echo "$current_time" >> "$output_file"
sleep 1
done
ファイルは、/home/test1にtest1.txtが出力される。
次に、/home/test1に/home/test2をbind mountをしてみる。
mount -o bind /home/test2 /home/test1
bind mount されても/home/test1 にあるファイルは見える。
以下のスクリプトで/home/test1/test2.txtというファイルで日付を出力してみる。
#!/bin/bash
output_file="./test1/test2.txt"
while true; do
current_time=$(date)
echo "$current_time"
echo "$current_time" >> "$output_file"
sleep 1
done
アンマウントをしてみる。
umount /home/test1
test1.txtが両方にあるが、bind mountをしたタイミングで吐き出し先が変わっている。
スクリプトが都度ファイルに書いているだけなのでそうなった。もし、ファイルが開きっぱなしでストリームとして出せているのであれば、元(/home/test1)へのI/Oが続いたはず。
パーティションの容量が足らない、でも他に余っているパーティションがあるのであれば、一次しのぎは可能。
いざというときには役にたつと思う。
それにしても、パーティションを切るときのサイズって、実際のアプリやデータがわからないと、決められないと思う。あるソフトが/tmpを酷使していたとしても、知らなかったら元も子もない。
Filesystem Standardというのが以下にあるが、
https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf
The /tmp directory must be made available for programs that require temporary files.
Programs must not assume that any files or directories in /tmp are preserved between invocations of the program.
Rationale
IEEE standard POSIX.1-2008 lists requirements similar to the above section.
Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted.
FHS added this recommendation on the basis of historical precedent and common practice, but did not make it a requirement because system administration is not within the scope of this standard.
/tmpの容量は、アドホックに使われるので推測はできない。/tmpが10GBで間に合うかどうかは、インストールするアプリケーションによってまちまち。容量がわからないのであれば、検証をして、実際のサイズを決めるか、エイやっで決めているなら、あえて切らないほうが安全かもしれない。/tmpは、誰でも書き込めるから、例えば、ユーザがISOイメージバンバンコピーをしたらすぐパンクする。他のマウントポイントと比べると書き込みの制限がなく、フリーダム。大学のとき、Quotaの目を盗むために、勝手にデータを置いていた輩がいて、パンクすることもあったし。
なので、自分は/tmpを切りたくはない。OSのインストーラーですら/tmpを作ることも強制していないし。
切るべきだという人は、聞き齧った昔の話の単なる受け売りだと思う。今の日本は、そんな聞き齧りが銀行のシステムが止まったり、会社間の問題になったりするのではと思ってしまう。