忘れないうちに書いておく。

vi /sys/module/md_mod/parameters/start_dirty_degraded

で 0→1 にする。

自宅LinuxサーバはRAID1で運用しており1年ごとに片肺交換を行なっている。HDD単体でみると2年使用して交換していることになる。
これまで4Tのドライブを使用していたが前回交換の際に6Tとした。今回もう片肺も6Tとし晴れて6T使用できる状況となったため認識容量の拡張を行なった。

因みに前回4TのRAID1に6Tのパーティションを追加しても容量は4Tのまま。片肺が4Tなのだから当然で新HDDの2Tは遊んでいることになる。今回もう片方も6Tのパーティションとなり全領域が使用できる状態ではあるが、RAIDサイズもファイルシステムも勝手には拡張してくれない。ちゃんと指示してあげる必要がある。

なお全ての操作はオンライン(マウントしたまま)の状態で操作可能。備忘録のため詳細は省くが操作自体は簡単で一瞬で完了する。

先ずはRAID1の拡張。パーティションの最大までとする。

mdadm --grow /dev/md1 -z max --assume-clean

オプションの「--assume-clean」は拡張部分のRAID再構築を省略するもの。理論的に再構築は不要。

次にファイルシステムをRAID1領域の最大まで拡張

resize2fs -p /dev/md1

オプションの「-p」は進行状況を見るプログレスバーを表示させるものだが、表示するまでもなく一瞬で終わった。

Ubuntu Server を構築する際、ルートパーティションは10GB程しか確保していませんでした。(/homeだけ別パーティション)

現在70％ほど使用していて(おそらく半分は古いカーネル類)、特に増える予定もなかったのですが、最近ふと見ると90％を超えていることがしばしば。対策をどうしようと頭を悩ませていたところ、どうも一時的なもので暫くするとまた70％程に落ち着くことが判ってきました。

90％を超えているときにプロセスを確認してみると、updatedb.mlocate というのがどうも怪しい。
で、いつものようにGoogle先生に聞いてみます。

どうもこれはファイル一覧のデータベースを更新しているもので、更新の際の一時ファイル(というか新dbファイル？)が要領を圧迫しているらしい。
そこでバックアップ関連のディレクトリを除外することにしました。

#vi /etc/updatedb.conf

とし

PRUNE_BIND_MOUNTS="yes"
PRUNEPATHS="/tmp /var/spool /media /mnt"
PRUNEFS="NFS nfs nfs4 rpc_pipefs afs binfmt_misc proc smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre_lite tmpfs usbfs udf fuse.glusterfs fuse.sshfs ecryptfs fusesmb devtmpfs"

太字の部分を追加。

私の場合、バックアップ元は別運営のNASで、バックアップ先は外付けHDDのため、マウントフォルダ全部を除外してしまうのが簡単です。

…と、これを書いているうちにdb更新が終了したようです。占有率が70％程に戻りました。

次のdb更新は明日の朝。うまく除外されているか確認しないといけませんね。

ちなみにdbファイルの場所は

/var/lib/mlocate

です。

--

最近大量購入しました。