こちらで軽く書いたけど、デスクトップ(ミドルタワー)のPCを作り直している。
元々は、Inter Core2Quadにメモリ8GBというマシン、それにWindows7(ホスト名 supernova)を導入して動かしていた。
こちらでWake On LANの対象にしていたマシンだ。
これを今回バラして、新しく買ったパーツを組み上げて、完全リフレッシュ、というのをやっている。
スペックは、Intel Core i7-6700にメモリ64GBだ。
コア数は同じ4つだが、Hyper Threadingによってスレッド数は倍の8、メモリは8倍の64GBに増強された。
色々紆余曲折はあったが、ようやくUbuntu16.04の導入が終わった。
(ホスト名は sagittarius にした。理由？そりゃ聖闘士星矢で射手座が重要なポジションだったからでしょ。)
ディスクレイアウトは、aquariusが120GBのSSDに対して、sagittariusは240GBのSSDだ。
基本的なレイアウトはaquariusと同じだが、/var/crashを68GBに、swapを128GBにしている。
それ以外は、「Ubuntu 16.04 導入」と同じだ。
これによって、supernovaがいなくなった。(再構築前にシステムバックアップは取得してあるが)
aquariusを作っている時と同じように、openvswitch設定やiSCSI設定などを行っている最中だ。
マザーボードのデフォルトで、Intel-vtやvt-d、オンボードEtherからのWoLが無効化されていたため、UEFIからそれらを有効化することも行っている。
今回のリフレッシュによって、Linux機2台構成になったため、aquariusからsupernovaを起動するWoLは外し、aqauriusからsagittraius、sagittariusからaquariusが相互にWoL出来るように設定を行った。
この設定に関しては、次回記載する。
2016年12月31日土曜日
2016年8月9日火曜日
仮想マシンのHDDを拡大
今、piscesのOS用仮想HDDは3.5GB、ariesのOS用仮想HDDは2GBしか割り当てていない。
(aquarius) $ virsh pool-list
名前 状態 自動起動
-------------------------------------------
default 動作中 はい (yes)
(aquarius) $ virsh pool-info default
名前: default
UUID: (略)
状態: 実行中
永続: はい (yes)
自動起動: はい (yes)
容量: 49.09 GiB
割り当て: 3.81 GiB
利用可能: 45.28 GiB
(aquarius) $ virsh vol-list --pool default
名前 パス
------------------------------------------------------------------------------
aries.qcow2 /var/lib/libvirt/images/aries.qcow2
pisces.qcow2 /var/lib/libvirt/images/pisces.qcow2
ubuntu-14.04.4-server-amd64.iso /var/lib/libvirt/images/ubuntu-14.04.4-server-amd64.iso
(aquarius) $ virsh vol-info pisces.qcow2 --pool default
名前: pisces.qcow2
タイプ: ファイル
容量: 3.50 GiB
割り当て: 1.85 GiB
(aquarius) $ virsh vol-info aries.qcow2 --pool default
名前: aries.qcow2
タイプ: ファイル
容量: 2.00 GiB
割り当て: 1.34 GiB
これでは、今後実験していく上で、あまりにも容量が少なすぎる。
これを拡大したい。
どれぐらいまで拡大できるだろうか？poolの利用可能容量が約45GBなので、それ以上に割り当てようとするとエラーになるのだろうか？
ちょっと試してみよう。
(念のため、仮想マシンは止めておくこと)
(aquarius) $ virsh vol-resize pisces.qcow2 72G --pool default
ボリューム 'pisces.qcow2' の容量を 72G に正常に変更しました
できたっぽい。
念のため確認。
(aquarius) $ virsh vol-info pisces.qcow2 --pool default
名前: pisces.qcow2
タイプ: ファイル
容量: 72.00 GiB
割り当て: 1.85 GiB
出来た。
一応、起動してゲストOS側から確認してみよう。
(aquarius) $ virsh start pisces
(pisces) $ sudo parted /dev/vda print
モデル: Virtio Block Device (virtblk)
ディスク /dev/vda: 77.3GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: msdos
番号 開始 終了 サイズ タイプ ファイルシステム フラグ
1 1049kB 256MB 255MB primary ext2 boot
2 257MB 3757MB 3500MB extended
5 257MB 3757MB 3500MB logical lvm
どうやら、拡大されているっぽいな。
ただし、パーティションサイズとpv(Phisical Volume)は構築当初のサイズのままだ。
これを拡大しないといけない。(末尾まで延ばしてしまおう)
まずはパーティションの拡大だ。(mbr形式の拡張領域なので、拡張パーティションと論理パーティションの両方を拡大する必要があるぞ。)
(pisces) $ sudo parted /dev/vda resizepart 2 100%
(pisces) $ sudo parted /dev/vda print
モデル: Virtio Block Device (virtblk)
ディスク /dev/vda: 77.3GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: msdos
番号 開始 終了 サイズ タイプ ファイルシステム フラグ
1 1049kB 256MB 255MB primary ext2 boot
2 257MB 77.3GB 77.1GB extended
5 257MB 3757MB 3500MB logical lvm
(pisces) $ sudo parted /dev/vda resizepart 5 100%
(pisces) $ sudo parted /dev/vda print
モデル: Virtio Block Device (virtblk)
ディスク /dev/vda: 77.3GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: msdos
番号 開始 終了 サイズ タイプ ファイルシステム フラグ
1 1049kB 256MB 255MB primary ext2 boot
2 257MB 77.3GB 77.1GB extended
5 257MB 77.3GB 77.1GB logical lvm
次いで、Phisical Volumeの拡張だ。これ上手くいくかな？
(pisces) $ sudo pvs /dev/vda5
PV VG Fmt Attr PSize PFree
/dev/vda5 pisces-vg lvm2 a-- 3.26g 0
(pisces) $ sudo vgs pisces-vg
VG #PV #LV #SN Attr VSize VFree
pisces-vg 1 2 0 wz--n- 3.26g 0
(pisces) $ sudo pvresize /dev/vda5
Physical volume "/dev/vda5" changed
1 physical volume(s) resized / 0 physical volume(s) not resized
(pisces) $ sudo pvs /dev/vda5
PV VG Fmt Attr PSize PFree
/dev/vda5 pisces-vg lvm2 a-- 71.76g 68.50g
(pisces) $ sudo vgs pisces-vg
VG #PV #LV #SN Attr VSize VFree
pisces-vg 1 2 0 wz--n- 71.76g 68.50g
あっさり拡張できてしまった。
ついでに、/領域(/dev/pisces-vg/root)も4GBに拡張しておこう。
(pisces) $ sudo lvs /dev/pisces-vg/root
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
root pisces-vg -wi-ao--- 2.76g
(pisces) $ sudo lvextend -L 4G pisces-vg/root
Extending logical volume root to 4.00 GiB
Logical volume root successfully resized
(pisces) $ sudo lvs /dev/pisces-vg/root
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
root pisces-vg -wi-ao--- 4.00g
(pisces) $ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/pisces--vg-root 2.7G 1.2G 1.4G 46% /
(pisces) $ sudo resize2fs /dev/pisces-vg/root
Filesystem at /dev/pisces-vg/root is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/pisces-vg/root is now 1048576 blocks long.
(pisces) $ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/pisces--vg-root 3.9G 1.2G 2.6G 31% /
piscesの拡張が出来たので、piscesは一旦シャットダウンしておこう。
(pisces) $ sudo shutdown -h now
ariesも同じように拡張しておく。
やり方は同じなので、コマンドだけ羅列しておく。
(aquarius) $ virsh vol-resize aries.qcow2 72G --pool default
(aquarius) $ virsh vol-info aries.qcow2 --pool default
(aquarius) $ virsh start aries
(aries) $ sudo parted /dev/vda print
(aries) $ sudo parted /dev/vda resizepart 2 100%
(aries) $ sudo parted /dev/vda print
(aries) $ sudo parted /dev/vda resizepart 5 100%
(aries) $ sudo parted /dev/vda print
(aries) $ sudo pvs /dev/vda5
(aries) $ sudo vgs aries-vg
(aries) $ sudo pvresize /dev/vda5
(aries) $ sudo pvs /dev/vda5
(aries) $ sudo vgs aries-vg
(aries) $ sudo lvs /dev/aries-vg/root
(aries) $ sudo lvextend -L 4G aries-vg/root
(aries) $ sudo lvs /dev/aries-vg/root
(aries) $ df -h /
(aries) $ sudo resize2fs /dev/aries-vg/root
(aries) $ df -h /
(aries) $ sudo shutdown -h now
終わった後のpoolの状態も確認しておこう。
(aquarius) $ virsh pool-info default
名前: default
UUID: (略)
状態: 実行中
永続: はい (yes)
自動起動: はい (yes)
容量: 49.09 GiB
割り当て: 3.81 GiB
利用可能: 45.28 GiB
問題なさそうだ。
(aquarius) $ virsh pool-list
名前 状態 自動起動
-------------------------------------------
default 動作中 はい (yes)
(aquarius) $ virsh pool-info default
名前: default
UUID: (略)
状態: 実行中
永続: はい (yes)
自動起動: はい (yes)
容量: 49.09 GiB
割り当て: 3.81 GiB
利用可能: 45.28 GiB
(aquarius) $ virsh vol-list --pool default
名前 パス
------------------------------------------------------------------------------
aries.qcow2 /var/lib/libvirt/images/aries.qcow2
pisces.qcow2 /var/lib/libvirt/images/pisces.qcow2
ubuntu-14.04.4-server-amd64.iso /var/lib/libvirt/images/ubuntu-14.04.4-server-amd64.iso
(aquarius) $ virsh vol-info pisces.qcow2 --pool default
名前: pisces.qcow2
タイプ: ファイル
容量: 3.50 GiB
割り当て: 1.85 GiB
(aquarius) $ virsh vol-info aries.qcow2 --pool default
名前: aries.qcow2
タイプ: ファイル
容量: 2.00 GiB
割り当て: 1.34 GiB
これでは、今後実験していく上で、あまりにも容量が少なすぎる。
これを拡大したい。
どれぐらいまで拡大できるだろうか？poolの利用可能容量が約45GBなので、それ以上に割り当てようとするとエラーになるのだろうか？
ちょっと試してみよう。
(念のため、仮想マシンは止めておくこと)
(aquarius) $ virsh vol-resize pisces.qcow2 72G --pool default
ボリューム 'pisces.qcow2' の容量を 72G に正常に変更しました
できたっぽい。
念のため確認。
(aquarius) $ virsh vol-info pisces.qcow2 --pool default
名前: pisces.qcow2
タイプ: ファイル
容量: 72.00 GiB
割り当て: 1.85 GiB
出来た。
一応、起動してゲストOS側から確認してみよう。
(aquarius) $ virsh start pisces
(pisces) $ sudo parted /dev/vda print
モデル: Virtio Block Device (virtblk)
ディスク /dev/vda: 77.3GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: msdos
番号 開始 終了 サイズ タイプ ファイルシステム フラグ
1 1049kB 256MB 255MB primary ext2 boot
2 257MB 3757MB 3500MB extended
5 257MB 3757MB 3500MB logical lvm
どうやら、拡大されているっぽいな。
ただし、パーティションサイズとpv(Phisical Volume)は構築当初のサイズのままだ。
これを拡大しないといけない。(末尾まで延ばしてしまおう)
まずはパーティションの拡大だ。(mbr形式の拡張領域なので、拡張パーティションと論理パーティションの両方を拡大する必要があるぞ。)
(pisces) $ sudo parted /dev/vda resizepart 2 100%
(pisces) $ sudo parted /dev/vda print
モデル: Virtio Block Device (virtblk)
ディスク /dev/vda: 77.3GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: msdos
番号 開始 終了 サイズ タイプ ファイルシステム フラグ
1 1049kB 256MB 255MB primary ext2 boot
2 257MB 77.3GB 77.1GB extended
5 257MB 3757MB 3500MB logical lvm
(pisces) $ sudo parted /dev/vda resizepart 5 100%
(pisces) $ sudo parted /dev/vda print
モデル: Virtio Block Device (virtblk)
ディスク /dev/vda: 77.3GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: msdos
番号 開始 終了 サイズ タイプ ファイルシステム フラグ
1 1049kB 256MB 255MB primary ext2 boot
2 257MB 77.3GB 77.1GB extended
5 257MB 77.3GB 77.1GB logical lvm
次いで、Phisical Volumeの拡張だ。これ上手くいくかな？
(pisces) $ sudo pvs /dev/vda5
PV VG Fmt Attr PSize PFree
/dev/vda5 pisces-vg lvm2 a-- 3.26g 0
(pisces) $ sudo vgs pisces-vg
VG #PV #LV #SN Attr VSize VFree
pisces-vg 1 2 0 wz--n- 3.26g 0
(pisces) $ sudo pvresize /dev/vda5
Physical volume "/dev/vda5" changed
1 physical volume(s) resized / 0 physical volume(s) not resized
(pisces) $ sudo pvs /dev/vda5
PV VG Fmt Attr PSize PFree
/dev/vda5 pisces-vg lvm2 a-- 71.76g 68.50g
(pisces) $ sudo vgs pisces-vg
VG #PV #LV #SN Attr VSize VFree
pisces-vg 1 2 0 wz--n- 71.76g 68.50g
あっさり拡張できてしまった。
ついでに、/領域(/dev/pisces-vg/root)も4GBに拡張しておこう。
(pisces) $ sudo lvs /dev/pisces-vg/root
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
root pisces-vg -wi-ao--- 2.76g
(pisces) $ sudo lvextend -L 4G pisces-vg/root
Extending logical volume root to 4.00 GiB
Logical volume root successfully resized
(pisces) $ sudo lvs /dev/pisces-vg/root
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
root pisces-vg -wi-ao--- 4.00g
(pisces) $ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/pisces--vg-root 2.7G 1.2G 1.4G 46% /
(pisces) $ sudo resize2fs /dev/pisces-vg/root
Filesystem at /dev/pisces-vg/root is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/pisces-vg/root is now 1048576 blocks long.
(pisces) $ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/pisces--vg-root 3.9G 1.2G 2.6G 31% /
piscesの拡張が出来たので、piscesは一旦シャットダウンしておこう。
(pisces) $ sudo shutdown -h now
ariesも同じように拡張しておく。
やり方は同じなので、コマンドだけ羅列しておく。
(aquarius) $ virsh vol-resize aries.qcow2 72G --pool default
(aquarius) $ virsh vol-info aries.qcow2 --pool default
(aquarius) $ virsh start aries
(aries) $ sudo parted /dev/vda print
(aries) $ sudo parted /dev/vda resizepart 2 100%
(aries) $ sudo parted /dev/vda print
(aries) $ sudo parted /dev/vda resizepart 5 100%
(aries) $ sudo parted /dev/vda print
(aries) $ sudo pvs /dev/vda5
(aries) $ sudo vgs aries-vg
(aries) $ sudo pvresize /dev/vda5
(aries) $ sudo pvs /dev/vda5
(aries) $ sudo vgs aries-vg
(aries) $ sudo lvs /dev/aries-vg/root
(aries) $ sudo lvextend -L 4G aries-vg/root
(aries) $ sudo lvs /dev/aries-vg/root
(aries) $ df -h /
(aries) $ sudo resize2fs /dev/aries-vg/root
(aries) $ df -h /
(aries) $ sudo shutdown -h now
終わった後のpoolの状態も確認しておこう。
(aquarius) $ virsh pool-info default
名前: default
UUID: (略)
状態: 実行中
永続: はい (yes)
自動起動: はい (yes)
容量: 49.09 GiB
割り当て: 3.81 GiB
利用可能: 45.28 GiB
問題なさそうだ。
2016年5月5日木曜日
Ubuntu 16.04 導入
というわけで、Ubuntuの新しいバージョン16.04を導入した。(サーバ版)
今までの15.10からアップグレードしてもいいんだけど、今回は真っさらにして入れ直した。完全に素の16.04にしたかったからだ。
ホスト名やIPアドレスはそのまま。だけど、LVMのレイアウトだけは変更した。
ざっくり以下の表の通りだ。
結局、/ と /usr は別領域に分割した。
それに合わせて、/usr/shareは独立させず、/usrと同じ領域にした。
また、/var/cache/aptを別領域に独立させた。
結果的に、lvol数が増えてしまったけど、ま、特に問題はないだろう。
後は、15.10の時と同様に、IPアドレスの固定化、ssh鍵の配置、バックアップ設定を施し、バックアップを実行した。
これで色々試してみるが、次は2回(の予定)に分けて、外部側(The Internet側)からのsshログインについて記載する予定だ。
今までの15.10からアップグレードしてもいいんだけど、今回は真っさらにして入れ直した。完全に素の16.04にしたかったからだ。
ホスト名やIPアドレスはそのまま。だけど、LVMのレイアウトだけは変更した。
ざっくり以下の表の通りだ。
| ボリューム | ファイルシステム | マウントポイント | 容量 | その他メモ |
|---|---|---|---|---|
| /dev/sda1 | vfat | /boot/efi | 512M | EFI System Partition |
| /dev/sda2 | ext2 | /boot | 512M | |
| /dev/vg-root/lv-root | ext4 | / | 2048M | |
| /dev/vg-root/lv-etc-opt | ext4 | /etc/opt | 32M | |
| /dev/vg-root/lv-home | ext4 | /home | 1024M | |
| /dev/vg-root/lv-opt | ext4 | /opt | 32M | |
| /dev/vg-root/lv-srv | ext4 | /srv | 32M | |
| /dev/vg-root/lv-tmp | ext4 | /tmp | 1024M | |
| /dev/vg-root/lv-usr | ext4 | /usr | 4096M | |
| /dev/vg-root/lv-usr-local | ext4 | /usr/local | 32M | |
| /dev/vg-root/lv-var | ext4 | /var | 2048M | |
| /dev/vg-root/lv-var-backups | ext4 | /var/backups | 32M | |
| /dev/vg-root/lv-var-cache | ext4 | /var/cache | 1024M | |
| /dev/vg-root/lv-var-cache-apt | ext4 | /var/cache/apt | 2048M | |
| /dev/vg-root/lv-var-crash | ext4 | /var/crash | 20480M | |
| /dev/vg-root/lv-var-local | ext4 | /var/local | 32M | |
| /dev/vg-root/lv-var-log | ext4 | /var/log | 1024M | |
| /dev/vg-root/lv-var-opt | ext4 | /var/opt | 32M | |
| /dev/vg-root/lv-var-tmp | ext4 | /var/tmp | 1024M | |
| /dev/vg-root/lv-swap-1 | swap | (swap) | 32768M |
それに合わせて、/usr/shareは独立させず、/usrと同じ領域にした。
また、/var/cache/aptを別領域に独立させた。
結果的に、lvol数が増えてしまったけど、ま、特に問題はないだろう。
後は、15.10の時と同様に、IPアドレスの固定化、ssh鍵の配置、バックアップ設定を施し、バックアップを実行した。
これで色々試してみるが、次は2回(の予定)に分けて、外部側(The Internet側)からのsshログインについて記載する予定だ。
2016年2月8日月曜日
ディスクレイアウトについて
先の記事にも書いたけど、ディスクレイアウトは結構細かくしている。
ざっと以下のような感じだ。
こんな風に細かく分けるのは、昔はそれなりに意味があったが、今じゃ単なる趣味のレベルだ。
強いて言うのなら、
とは言っても、ほとんどの領域をext4で作っているので、ファイルシステムタイプを選ぶメリットは活かせていないし、バックアップ・リストアも全領域一括で行うことを考えているので、そのメリットもない。
あくまで趣味の世界だ。
昔だったら、 / と /usr は分けていた。というか、今でも分けたいと思っている。
先の記事にも書いたけど、最近のトレンドは / と /usr を分けない方向にあるみたいなので(RedHat は分けないことを推奨している模様)、それに倣ったというのが実情。
ただし、 /usr はただでさえでかいディレクトリなので、その中でも分割可能そうなディレクトリはボリューム分割した。
/boot がLVM領域じゃないのは、ubuntuを何も考えずにお任せインストールすると、 /boot がLVM領域じゃなく、単なるパーテイションになるから、それに従った。
ホントは、LVM領域にしたかったんだけどね。
ファイルシステムに ext4 を選んで、 xfs を選ばなかった理由は、この後記載するバックアップ・リストアに関連している。
リストア時は、OSメディア(ubuntu serverのCD-Rメディア)で boot して、復旧用に shell を立ち上げ、そこからリストアを行うことを想定している。
んが、ubuntu server のメディアで boot すると、xfsファイルシステムを作るための mkfs.xfs コマンドが無いんだ。
だから ext4 にした。
あと、 /var/crash なんだけど、デフォルトでは kdump がインストールされないみたいなので、わざわざ確保してもあまり意味が無い。
更に、 crash-dump が吐き出されても、解析できるだけの力があるわけじゃないので、意味なしなんだ。まぁ、なんとなく、ね。
ディスクレイアウトとファイルシステムに関してはこんな感じ。
P.S.
今回のマシンは uEFI が使われている。 /boot/efi は uEFI ブートを行う場合に必要な領域で、レガシーBIOSからブートする場合は不要。ただ、もう uEFI が当たり前の時代になっているっぽいので、それに従って uEFI モードにしてある。
2016/03/23追記
どうやら、メディアブートしても、ちゃんと mkfs.xfs は使えるようだ。
コマンドとしては存在しないけど、メディアブートした時に使うコマンド集合体であるbusyboxには、mkfs.xfs が組み込まれているようだ。
なので、「メディアブート時に mkfs.xfs が使えないから、OSのファイルシステムとして xfs は使わない」は間違いだった。
実は、xfsは別の理由でも使えなかった。自分がxfsの特性を分かっていないので、トンデモない勘違いをしているかもしれないけど…。
LVMで作られた領域(lvol)をxfsでフォーマットしてマウントしていた状態で、そのlvolのLVMスナップショットを作成、そのスナップショットをマウントしようとすると、xfs内部のuuidが、既にマウントされているものと同じ、という理由でマウント出来なかった。
この辺り、まだまだ調べておく必要が有る。
ということで、xfsのクセが理解出来ていないので、ext4を用いる方針は変えず。(いつかxfs使いたい。)
ざっと以下のような感じだ。
| ボリューム | ファイルシステム | マウントポイント | 容量 | その他メモ |
|---|---|---|---|---|
| /dev/sda1 | vfat | /boot/efi | 512M | EFI System Partition |
| /dev/sda2 | ext2 | /boot | 512M | |
| /dev/vg-root/lv-root | ext4 | / | 8192M | |
| /dev/vg-root/lv-etc-opt | ext4 | /etc/opt | 32M | |
| /dev/vg-root/lv-home | ext4 | /home | 1024M | |
| /dev/vg-root/lv-opt | ext4 | /opt | 32M | |
| /dev/vg-root/lv-srv | ext4 | /srv | 32M | |
| /dev/vg-root/lv-tmp | ext4 | /tmp | 1024M | |
| /dev/vg-root/lv-usr-local | ext4 | /usr/local | 32M | |
| /dev/vg-root/lv-usr-share | ext4 | /usr/share | 2048M | |
| /dev/vg-root/lv-var | ext4 | /var | 2048M | |
| /dev/vg-root/lv-var-backups | ext4 | /var/backups | 32M | |
| /dev/vg-root/lv-var-cache | ext4 | /var/cache | 2048M | |
| /dev/vg-root/lv-var-crash | ext4 | /var/crash | 20480M | |
| /dev/vg-root/lv-var-local | ext4 | /var/local | 32M | |
| /dev/vg-root/lv-var-log | ext4 | /var/log | 1024M | |
| /dev/vg-root/lv-var-opt | ext4 | /var/opt | 32M | |
| /dev/vg-root/lv-var-tmp | ext4 | /var/tmp | 1024M | |
| /dev/vg-root/lv-swap-1 | swap | (swap) | 32768M |
強いて言うのなら、
- 特定ディレクトリの使用量が突然膨らんでも、他のディレクトリには影響しない
- 何かのプログラムが、使われてないはずのディレクトリ(/srv等、32Mで指定した領域)を使っていても、すぐに気付ける
- バックアップ・リストアの単位を細かくできる
- 使用目的ごとに、ファイルシステムタイプを選ぶことが出来る
とは言っても、ほとんどの領域をext4で作っているので、ファイルシステムタイプを選ぶメリットは活かせていないし、バックアップ・リストアも全領域一括で行うことを考えているので、そのメリットもない。
あくまで趣味の世界だ。
昔だったら、 / と /usr は分けていた。というか、今でも分けたいと思っている。
先の記事にも書いたけど、最近のトレンドは / と /usr を分けない方向にあるみたいなので(RedHat は分けないことを推奨している模様)、それに倣ったというのが実情。
ただし、 /usr はただでさえでかいディレクトリなので、その中でも分割可能そうなディレクトリはボリューム分割した。
/boot がLVM領域じゃないのは、ubuntuを何も考えずにお任せインストールすると、 /boot がLVM領域じゃなく、単なるパーテイションになるから、それに従った。
ホントは、LVM領域にしたかったんだけどね。
ファイルシステムに ext4 を選んで、 xfs を選ばなかった理由は、この後記載するバックアップ・リストアに関連している。
リストア時は、OSメディア(ubuntu serverのCD-Rメディア)で boot して、復旧用に shell を立ち上げ、そこからリストアを行うことを想定している。
んが、ubuntu server のメディアで boot すると、xfsファイルシステムを作るための mkfs.xfs コマンドが無いんだ。
だから ext4 にした。
あと、 /var/crash なんだけど、デフォルトでは kdump がインストールされないみたいなので、わざわざ確保してもあまり意味が無い。
更に、 crash-dump が吐き出されても、解析できるだけの力があるわけじゃないので、意味なしなんだ。まぁ、なんとなく、ね。
ディスクレイアウトとファイルシステムに関してはこんな感じ。
P.S.
今回のマシンは uEFI が使われている。 /boot/efi は uEFI ブートを行う場合に必要な領域で、レガシーBIOSからブートする場合は不要。ただ、もう uEFI が当たり前の時代になっているっぽいので、それに従って uEFI モードにしてある。
2016/03/23追記
どうやら、メディアブートしても、ちゃんと mkfs.xfs は使えるようだ。
コマンドとしては存在しないけど、メディアブートした時に使うコマンド集合体であるbusyboxには、mkfs.xfs が組み込まれているようだ。
なので、「メディアブート時に mkfs.xfs が使えないから、OSのファイルシステムとして xfs は使わない」は間違いだった。
実は、xfsは別の理由でも使えなかった。自分がxfsの特性を分かっていないので、トンデモない勘違いをしているかもしれないけど…。
LVMで作られた領域(lvol)をxfsでフォーマットしてマウントしていた状態で、そのlvolのLVMスナップショットを作成、そのスナップショットをマウントしようとすると、xfs内部のuuidが、既にマウントされているものと同じ、という理由でマウント出来なかった。
この辺り、まだまだ調べておく必要が有る。
ということで、xfsのクセが理解出来ていないので、ext4を用いる方針は変えず。(いつかxfs使いたい。)
登録:
投稿 (Atom)