論理ボリュームのサイズを変更する正しい方法が何であるかを理解しようとしています(追加のpvを追加せずに1つの論理ボリュームを縮小し、別の論理ボリュームを拡張したい)。
私が理解する限り、このリンクによると:Chrisのlvmガイド、そしてVLMについて私が読んだ他のソースから正しい方法は次のとおりです。
1. Shrink the file system of lv #1
2. Shrink the lv #1 size
3. extend the lv #2 size
4. fix/extend the file system of lv #2
また、LVM(PVはVGにマッピングされ、VGはLVにマッピング)のアーキテクチャも理解しています。
私のギャップは次のとおりです
- 計画に追加PVを追加しない場合は、LUKSに興味を持っている必要がありますか?それとも、PVが変わらない限り、このプロセスがLUKSに影響を与えないということですか?
- パーティションとPVは1つの単位で暗号化されますか、それとも各レベルが個別に暗号化されますか?
- 私の場合は、サイズ変更したいと思い、
/tmp
私の/var
アーキテクチャに従ってキーのディスクから起動し、livecdから起動する必要がありますか、それともホスト自体から起動できますか?
太陽電池スキャン
PV /dev/nvme0n1p3 VG fedora_localhost-live lvm2 [475.35 GiB / 4.00 MiB free]
Total: 1 [475.35 GiB] / in use: 1 [475.35 GiB] / in no VG: 0 [0 ]
スキャナー
Found volume group "fedora_localhost-live" using metadata type lvm2
左にスキャン
ACTIVE '/dev/fedora_localhost-live/root' [70.00 GiB] inherit
ACTIVE '/dev/fedora_localhost-live/home' [<348.35 GiB] inherit
ACTIVE '/dev/fedora_localhost-live/swap' [38.00 GiB] inherit
ACTIVE '/dev/fedora_localhost-live/var' [4.00 GiB] inherit
ACTIVE '/dev/fedora_localhost-live/tmp' [15.00 GiB] inherit
df-h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 16G 0 16G 0% /dev
tmpfs 16G 124M 16G 1% /dev/shm
tmpfs 16G 2.4M 16G 1% /run
/dev/dm-2 69G 9.9G 56G 16% /
/dev/nvme0n1p2 976M 232M 678M 26% /boot
/dev/nvme0n1p1 599M 30M 570M 5% /boot/efi
/dev/sda1 826G 783G 44G 95% /mnt/workspace_HDD
/dev/dm-7 3.9G 3.0G 720M 81% /var
/dev/loop0 182M 182M 0 100% /var/lib/snapd/snap/spotify/36
/dev/loop1 90M 90M 0 100% /var/lib/snapd/snap/core/8268
/dev/dm-8 342G 3.8G 321G 2% /home
/dev/dm-9 15G 41M 14G 1% /tmp
tmpfs 3.2G 112K 3.2G 1% /run/user/1000
また、Fedoraが実行するマッピングとコマンドにどのパスが使用されているかを知りたいです。 lvreduce/lvexdend/resize2fs: lvごとに「2つの」パス(1つは論理ボリューム用、1つは論理ボリューム用)がある理由を理解すると思います。論理ボリューム2番目は復号化されたボリュームです。
ls -l /dev/マッパー/
total 0
crw-------. 1 root root 10, 236 Jan 18 18:10 control
lrwxrwxrwx. 1 root root 7 Jan 18 18:10 fedora_localhost--live-home -> ../dm-4
lrwxrwxrwx. 1 root root 7 Jan 18 18:10 fedora_localhost--live-root -> ../dm-0
lrwxrwxrwx. 1 root root 7 Jan 18 18:10 fedora_localhost--live-swap -> ../dm-1
lrwxrwxrwx. 1 root root 7 Jan 18 18:10 fedora_localhost--live-tmp -> ../dm-6
lrwxrwxrwx. 1 root root 7 Jan 18 18:10 fedora_localhost--live-var -> ../dm-5
lrwxrwxrwx. 1 root root 7 Jan 18 18:10 luks-3b985124-40c1-450b-8740-da85a6083aa5 -> ../dm-8
lrwxrwxrwx. 1 root root 7 Jan 18 18:10 luks-7791d468-c71b-4603-942e-5a30efc8d3fd -> ../dm-9
lrwxrwxrwx. 1 root root 7 Jan 18 18:10 luks-d695f07d-2017-4e36-a792-851cb23d26d1 -> ../dm-2
lrwxrwxrwx. 1 root root 7 Jan 18 18:10 luks-e0d65c04-dfdb-4f61-8b2f-0b76127eaf8e -> ../dm-3
lrwxrwxrwx. 1 root root 7 Jan 18 18:10 luks-f5400a56-7498-4a73-ab1b-40c331e74d6f -> ../dm-7
最後のコマンドは次のとおりです。 LSBLK
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 181.1M 1 loop /var/lib/snapd/snap/spotify/36
loop1 7:1 0 89.1M 1 loop /var/lib/snapd/snap/core/8268
sda 8:0 0 953.9G 0 disk
├─sda1 8:1 0 825.9G 0 part /mnt/workspace_HHD
└─sda2 8:2 0 128G 0 part
sr0 11:0 1 1024M 0 rom
nvme0n1 259:0 0 477G 0 disk
├─nvme0n1p1 259:1 0 600M 0 part /boot/efi
├─nvme0n1p2 259:2 0 1G 0 part /boot
└─nvme0n1p3 259:3 0 475.4G 0 part
├─fedora_localhost--live-root 253:0 0 70G 0 lvm
│ └─luks-d695f07d-2017-4e36-a792-851cb23d26d1 253:2 0 70G 0 crypt /
├─fedora_localhost--live-swap 253:1 0 38G 0 lvm
│ └─luks-e0d65c04-dfdb-4f61-8b2f-0b76127eaf8e 253:3 0 38G 0 crypt [SWAP]
├─fedora_localhost--live-home 253:4 0 348.4G 0 lvm
│ └─luks-3b985124-40c1-450b-8740-da85a6083aa5 253:8 0 348.3G 0 crypt /home
├─fedora_localhost--live-var 253:5 0 4G 0 lvm
│ └─luks-f5400a56-7498-4a73-ab1b-40c331e74d6f 253:7 0 4G 0 crypt /var
└─fedora_localhost--live-tmp 253:6 0 15G 0 lvm
└─luks-7791d468-c71b-4603-942e-5a30efc8d3fd 253:9 0 15G 0 crypt /tmp
出力によるとLSBLK各lvが1単位で暗号化されているようです。それとも私の考えが間違っていますか?
LUKSなしでLVMがどのように機能するかを理解し、LVMなしでLUKSがどのように機能するかを理解すると思います。しかし、私は彼らがどのように連携するのか、それらの関係が何であるか、そして私のような状況でlukが存在するときに論理ボリュームのサイズを実際に調整する方法を理解していません。
ありがとうございます。
答え1
LVMにはLUKSがあるため、LUKSに気を付ける必要があります。lvresize --resizefs
ここではうまくいかないので、手動で行う必要があります。
LUKS がない場合、LV のサイズとファイルシステムのサイズは同じです。 LUKSの場合は、LUKSヘッダも考慮する必要があります。ヘッダーは数MiBより大きいため、ファイルシステムは数MiBより小さくなければならず、論理ボリュームは数MiBより大きくなければなりません。したがって、LUKS ヘッダーとファイルシステムの両方に十分なスペースがあります。
(比較、ペイロード、またはデータオフセット)のLUKSヘッダーサイズ/home
に縮小するとします。100G
16M
cryptsetup luksDump
ファイルシステムを作成する場合は、/home
LVのサイズを100G
決定する必要があります。100G+16M
100G-16M
または、LVが明確になるようにファイルシステムのサイズを変更してください100G
。
たとえば、次のようになります。
# shrink the filesystem first
resize2fs /dev/mapper/luks-home 100G
# shrink the LUKS
cryptsetup resize --device-size 100G luks-home
# shrink the LV
lvresize -L102416M lvm/home # 100G = 102400M + 16M
数学的にわからない場合は、ファイルシステムをさらに縮小(例:100Gではなく99G)して、安全余裕を追加してから、後で「実際の」デバイスサイズに復元するのが一般的です。
# after resizing the LV, grow LUKS and filesystem to device size
cryptsetup resize luks-home
resize2fs /dev/mapper/luks-home
従来のパーティション化とは異なり、LVM を使用すると、利用可能なすべてのスペースを一度に使用する理由はありません。 LVのサイズがより合理的である場合、まず面倒な縮小プロセスを必要とせずに必要に応じてファイルシステムを拡張するのに十分な空きLVMスペースがあります。
答え2
時間がかかりましたが、仮想マシンで試行錯誤を受けた後(作業する前に数台のマシンを破壊することができたので、実際のシステムでこれを行う前に練習してください)、ここで大きな助けを得て、すぐに成功しました。次のように、lvmのLV設定luksを減らします。
- ライブCDを起動し、回復モードに入ります。
パーティションの復号化
cryptsetup open /dev/mapper/fedora_localhost--live-tmp tmpCrypt
ファイルシステムの縮小
resize2fs /dev/mapper/tmpcrypt 6G
LUKSパーティションを閉じる
cryptsetup close /dev/mapper/tmpCrypt
LUKSヘッダーの縮小
cryptsetup resize /dev/mapper/fedora_localhost--live-tmp
LVサイズの縮小(暗号化サイズ16M + LUKSヘッダサイズ= 6144 + 16)
sudo lvreduce -L 6160M /dev/mapper/fedora_localhost--live-tmp
LUKSのサイズを再調整してください
cryptsetup resize /dev/mapper/fedora_localhost--live-tmp
パーティションの復号化
cryptsetup open /dev/mapper/fedora_localhost--live-tmp tmpCrypt
ファイルシステムのサイズを再調整
sudo resize2fs /dev/mapper/tmpCrypt
*注:私の知る限り、ステップ8と9は必須ではありませんが、システムを再起動する前にファイルシステムを確認するために行いました。