Arch Linuxカーネル4.18.12-Arch1-1-Arch
(2018年11月)を使用しています。
古いラップトップのハードドライブを保持するSATAキャディ(Thinkpad T400用)を使用しています。内容を組み合わせて論理ボリュームrootvol
とlvhome
を拡張するか、現在の設定を維持するかを決定したいと思います(以下を参照)。私はext4
ファイルシステムのみを使用しており、両方のボリュームにデータが含まれています。この質問は答えられているようですが ここ 、データの損失を防ぐために何をすべきかわかりません。
そのため、現在、luks暗号化SSDから起動し、$HOME
にいくつかのシンボリックリンクがあり、レイジーマウントされたハードドライブ上のディレクトリを指してストレージを拡張し、ハードドライブ上の古い$HOME
を使用できるようにしています。
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT UUID
sda 8:0 0 223.6G 0 disk
└─sda1 8:1 0 223.6G 0 part 3d17c5b4-a603-4600-9f36-c598a7da783e
└─root 254:0 0 223.6G 0 crypt PRGLfW-Q18M-pPu8-nr6a-tloV-SS4W-kK1ROX
├─matrix-swapvol 254:1 0 2G 0 lvm [SWAP] 38e862ef-e919-4388-810f-63ce187b342c
└─matrix-rootvol 254:2 0 221.6G 0 lvm / c71a8292-c678-4a53-90da-3e4bf78cedbb
sdb 8:16 0 232.9G 0 disk
├─sdb1 8:17 0 512M 0 part 14c635fb-6ee7-45c0-aefd-d3d7440116c0
└─sdb2 8:18 0 232.4G 0 part c36535d9-4098-4939-9ebe-6a2be950f3ea
└─caddy 254:3 0 232.4G 0 crypt kTkSk4-oemR-1fJi-4brz-OXmW-DEZk-rqF2pN
├─vgarch-lvswap 254:4 0 4G 0 lvm a1932471-209e-4d47-85dc-c4ea1ce37de8
├─vgarch-lvroot 254:5 0 15G 0 lvm 67d37f85-c2c0-40e7-88e9-afd4a6c1c561
└─vgarch-lvhome 254:6 0 211.2G 0 lvm dd89d271-776a-426a-826d-9f4d7056fc6a
ご覧のとおり、何らかの理由で、luksでlvmを2回使用することにしました。 SSDには/boot
パーティションがないことに注意してください。librebootROM imageを使用して復号化されます。起動時に、/dev/sdb2
のUUIDのcrypttab
のエントリは、 /
のキーファイル。次に、systemdの自動マウントサービスを使用して、必要に応じてマウントまたはアンマウントします。
# /etc/fstab
# /dev/mapper/vgarch-lvhome
UUID=dd89d271-776a-426a-826d-9f4d7056fc6a /mnt/caddy ext4 rw,noatime,data=ordered,noauto,nofail,x-systemd.automount,x-systemd.device-timeout=20,x-systemd.idle-timeout=2min 0 0
lvhome
内のファイルの所有権を再帰的に変更しました。 lvroot
とlvswap
は必要ないので、/ bootを含む/ dev/sdb1と一緒に削除します。
では、これらをどのように組み合わせることができますか?それはお勧めですか? (SSDとHDDの用途が異なるため)最初にコンテンツを他のファイルシステムにコピーすることをお勧めしますが、これはlvmの目的を損なうものではありませんか?ファイルシステムを拡大または縮小するのは簡単だったと思いましたが、zfsの世界の機能を想像したと思います。
LVMは、論理ブロックデバイスである論理ボリュームを提供し、それらのブロックデバイスの拡張、縮小、再配置、スナップショットなどを容易にします。その後、これらのブロックデバイスを好きなように使用できます...ファイルシステム、または独自のパーティションテーブルとすべてを備えたVMの仮想HDDのようなものです。
LVMはファイルシステムレベルでは何もしません。したがって、これらの拡張または縮小されたブロックデバイスの処理をサポートするのはファイルシステム次第であり、パーティションテーブルのサイズを変更するのはVM)です。
ほとんどのファイルシステムは拡張をサポートしていますが(オンラインではない場合や、特定の制限を超えていない場合もあります)、一部のファイルシステムは縮小をサポートしていません。したがって、LVMにはブロックデバイスの縮小に関する問題はありませんが、最初にファイルシステムを縮小する必要があり、一部のファイルシステムではそれが不可能です。
通常、2つの別々のファイルシステムのコンテンツのマージはサポートされていません。
そうです、場合によっては、昔ながらの方法でファイルをコピーする必要があります。次に、それらのファイルが存在していたLVを破棄/削除し、解放されたスペースを使用してLVを拡張し、ファイルをコピーしたファイルシステムを拡張します。
では、これらをどのように組み合わせることができますか?それはお勧めですか? (SSDとHDDの用途が異なるため)
半分がSSDで、半分がHDDでバックアップされているブロックデバイスは作成しません。私はこれらを別々に保つのが好きです。
他の状況では意味があるかもしれません。 HDDが書き込みに設定されているSSD-HDD-RAID1を実行できます。ほとんどの場合、すべての読み取りは、より高速であるため、通常はSSDによって処理されます。ただし、SSDの価格が下がると、代わりに通常のRAID1に2つのSSDを使用できるため、このセットアップはあまり一般的ではありません。