Mdadm

mdadm 數組下的 md 分區是什麼？

  • January 13, 2020

我正在使用 設置兩個 RAID 1 陣列mdadm，它似乎工作正常，但是當我進行檢查時，lsblk我看到以下內容：

sda                      8:0    0   5,5T  0 disk  
└─md127                  9:127  0   5,5T  0 raid1 
 ├─data-crypt-1       253:5    0   5,5T  0 crypt 
 │ └─myVg-data        253:6    0   5,5T  0 lvm   
 ├─md127p1            259:5    0 182,4G  0 md    
 └─md127p2            259:6    0   1,2T  0 md    
sdb                      8:16   0   5,5T  0 disk  
└─md127                  9:127  0   5,5T  0 raid1 
 ├─data-crypt-1       253:5    0   5,5T  0 crypt 
 │ └─myVg-data        253:6    0   5,5T  0 lvm   
 ├─md127p1            259:5    0 182,4G  0 md    
 └─md127p2            259:6    0   1,2T  0 md    
sdc                      8:32   0   5,5T  0 disk  
└─md126                  9:126  0   5,5T  0 raid1 
sdd                      8:48   0   5,5T  0 disk  
└─md126                  9:126  0   5,5T  0 raid1

這些分區（？）在我md127p1的md127p2陣列中是什麼？我應該刪除它們嗎？如果是，如何刪除？

它似乎沒有乾擾陣列，它似乎正在按預期重新同步。但是我擔心，例如，如果有人要掛載說md127p1並向它寫一些東西，它會破壞其中的數據data-crypt-1（跨越整個驅動器）。

編輯：

重新啟動和重新組裝後問題（如果是問題）仍然存在。

sudo wipefs --no-act /dev/md127
# DEVICE OFFSET TYPE        UUID                                 LABEL
# md127  0x0    crypto_LUKS ba3eab9b-db06-4053-9eb8-4e674931148c

dmesg``md126確實報告和之間的行為略有不同md127。不知道如何檢查“背景重建”。

dmesg | grep "md12[67]"
# [    3.072445] md/raid1:md127: not clean -- starting background reconstruction
# [    3.072445] md/raid1:md127: active with 2 out of 2 mirrors
# [    3.107577] md127: detected capacity change from 0 to 6001039835136
# [    3.112944]  md127: AHDI p1 p2 p3
# [    4.072578] md/raid1:md126: active with 2 out of 2 mirrors
# [    4.105528] md126: detected capacity change from 0 to 6001039835136
# [  175.221344]  md127: AHDI p1 p2 p3
# [  252.627169]  md127: AHDI p1 p2 p3
# [  337.950292]  md127: AHDI p1 p2 p3

並udevadm報告如下：

udevadm info /dev/md127p1
# P: /devices/virtual/block/md127/md127p1
# N: md127p1
# L: 100
# S: disk/by-id/md-name-XYZ:data-array-1-part1
# S: disk/by-id/md-uuid-94gd622:d96sf22:9fb73768:dae5367e-part1
# S: md/XYZ:data-array-1p1
# E: DEVLINKS=/dev/md/XYZ:data-array-1p1 /dev/disk/by-id/md-name-XYZ:data-array-1-part1 /dev/disk/by-id/md-uuid-94gd622:d96sf22:9fb73768:dae5367e-part1
# E: DEVNAME=/dev/md127p1
# E: DEVPATH=/devices/virtual/block/md127/md127p1
# E: DEVTYPE=partition
# E: MAJOR=259
# E: MD_DEVICES=2
# E: MD_DEVICE_ev_sda_DEV=/dev/sda
# E: MD_DEVICE_ev_sda_ROLE=0
# E: MD_DEVICE_ev_sdb_DEV=/dev/sdb
# E: MD_DEVICE_ev_sdb_ROLE=1
# E: MD_DEVNAME=XYZ:data-array-1
# E: MD_LEVEL=raid1
# E: MD_METADATA=1.2
# E: MD_NAME=XYZ:data-array-1
# E: MD_UUID=94gd622:d96sf22:9fb73768:dae5367e
# E: MINOR=5
# E: PARTN=1
# E: SUBSYSTEM=block
# E: SYSTEMD_WANTS=mdmonitor.service
# E: TAGS=:systemd:
# E: USEC_INITIALIZED=337999178

udevadm info /dev/md127p2
# P: /devices/virtual/block/md127/md127p2
# N: md127p2
# L: 100
# S: disk/by-id/md-name-XYZ:data-array-1-part2
# S: disk/by-id/md-uuid-94gd622:d96sf22:9fb73768:dae5367e-part2
# S: md/XYZ:data-array-1p2
# E: DEVLINKS=/dev/disk/by-id/md-name-XYZ:data-array-1-part2 /dev/disk/by-id/md-uuid-94gd622:d96sf22:9fb73768:dae5367e-part2 /dev/md/XYZ:data-array-1p2
# E: DEVNAME=/dev/md127p2
# E: DEVPATH=/devices/virtual/block/md127/md127p2
# E: DEVTYPE=partition
# E: MAJOR=259
# E: MD_DEVICES=2
# E: MD_DEVICE_ev_sda_DEV=/dev/sda
# E: MD_DEVICE_ev_sda_ROLE=0
# E: MD_DEVICE_ev_sdb_DEV=/dev/sdb
# E: MD_DEVICE_ev_sdb_ROLE=1
# E: MD_DEVNAME=XYZ:data-array-1
# E: MD_LEVEL=raid1
# E: MD_METADATA=1.2
# E: MD_NAME=XYZ:data-array-1
# E: MD_UUID=94gd622:d96sf22:9fb73768:dae5367e
# E: MINOR=6
# E: PARTN=2
# E: SUBSYSTEM=block
# E: SYSTEMD_WANTS=mdmonitor.service
# E: TAGS=:systemd:
# E: USEC_INITIALIZED=337999612

hexdump顯示：

sudo hexdump -C -n 512 /dev/md127
# *
# *
# 000001c0  7c e8 03 4d 62 32 d5 66  37 75 6b e9 12 6d 16 cc  ||..Mb2.f7uk..m..|
# 000001d0  96 9e 6f 3d 32 e0 e7 fe  7f f4 9c a1 59 03 19 47  |..o=2.......Y..G|
# 000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
# *

我還注意到我在某些機器上看不到“幽靈”分區，尤其是我的 DietPi 機器上沒有顯示它們。它們確實顯示在我的 Ubuntu 機器上。此外，我注意到兩個陣列（md126 和 md127）都是在其中一台 DietPi 機器上創建的。

因此，這似乎是隨機偽造分區表錯誤檢測的情況。

這是 Atari / AHDI 分區表的範例（使用 parted 創建）：

# hexdump -C -n 512 /dev/loop0 
000001c0  00 00 00 03 20 00 01 4c  4e 58 00 00 08 00 00 00  |.... ..LNX......|
000001d0  08 00 01 4c 4e 58 00 00  18 00 00 00 60 00 00 50  |...LNX......`..P|
000001e0  41 52 54 45 44 41 54 41  52 49 00 50 41 52 54 45  |ARTEDATARI.PARTE|
000001f0  44 41 54 41 52 49 00 00  00 01 00 00 00 01 fa 70  |DATARI.........p|

所以有趣的一點是 GEM、BGM、LNX、SWP、RAW 中偏移量 0x1c0/0x1d0 行中的一個，如 block/partitions/atari.c#L27-L32 所示：

static inline int OK_id(char *s)
{
   return  memcmp (s, "GEM", 3) == 0 || memcmp (s, "BGM", 3) == 0 ||
       memcmp (s, "LNX", 3) == 0 || memcmp (s, "SWP", 3) == 0 ||
       memcmp (s, "RAW", 3) == 0 ;
}

這是 LUKS2 標頭的範例：

# hexdump -C -n 512 /dev/loop1
00000000  4c 55 4b 53 ba be 00 02  00 00 00 00 00 00 40 00  |LUKS..........@.|
00000010  00 00 00 00 00 00 00 03  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000040  00 00 00 00 00 00 00 00  73 68 61 32 35 36 00 00  |........sha256..|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  a4 43 6c 13 63 6b 33 da  |.........Cl.ck3.|
00000070  c8 f5 1d 7d 82 b3 9e dc  15 b2 ff 55 d2 4c 3e 8c  |...}.......U.L>.|
00000080  62 08 ec 0f 56 b2 bc 89  86 f0 e8 c0 e6 a2 d8 12  |b...V...........|
00000090  56 93 68 2f 83 82 e6 90  18 57 7b 23 34 d7 96 92  |V.h/.....W{#4...|
000000a0  ab ad 67 a5 d9 7d dd 6c  32 36 37 36 35 63 39 32  |..g..}.l26765c92|
000000b0  2d 34 34 37 34 2d 34 36  37 64 2d 62 39 62 62 2d  |-4474-467d-b9bb-|
000000c0  64 36 30 36 63 61 64 31  32 61 62 64 00 00 00 00  |d606cad12abd....|
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001c0  55 85 e9 50 c2 46 1e 16  27 a7 ce a5 9d e9 46 17  |U..P.F..'.....F.|
000001d0  fb 30 9a ae 53 74 39 8a  c5 2c d2 21 4b 86 ad 20  |.0..St9..,.!K.. |
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

所以恰好在相同的 0x1c0 / 0x1d0 行中有隨機數據。

我的猜測是你在其中隨機滾動了 GEM、BGM、LNX、SWP、RAW 之一，所以它看起來像核心的分區表，因此你檢測到了你的怪異分區。

好消息是，對於 LUKS2 標頭，這個偏移量似乎代表了標頭校驗和。每次您更改 LUKS2 標頭中的任何內容時，它都會完全改變，因此…例如，您可以添加另一個密碼。（如果您實際上不需要它，請將其刪除）。

# cryptsetup luksAddKey /dev/loop1
Enter any existing passphrase: 
Enter new passphrase for key slot: 
Verify passphrase:

執行後相同的 LUKS2 標頭cryptsetup luksAddKey：

# hexdump -C -n 512 /dev/loop1
00000000  4c 55 4b 53 ba be 00 02  00 00 00 00 00 00 40 00  |LUKS..........@.|
00000010  00 00 00 00 00 00 00 05  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000040  00 00 00 00 00 00 00 00  73 68 61 32 35 36 00 00  |........sha256..|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  a4 43 6c 13 63 6b 33 da  |.........Cl.ck3.|
00000070  c8 f5 1d 7d 82 b3 9e dc  15 b2 ff 55 d2 4c 3e 8c  |...}.......U.L>.|
00000080  62 08 ec 0f 56 b2 bc 89  86 f0 e8 c0 e6 a2 d8 12  |b...V...........|
00000090  56 93 68 2f 83 82 e6 90  18 57 7b 23 34 d7 96 92  |V.h/.....W{#4...|
000000a0  ab ad 67 a5 d9 7d dd 6c  32 36 37 36 35 63 39 32  |..g..}.l26765c92|
000000b0  2d 34 34 37 34 2d 34 36  37 64 2d 62 39 62 62 2d  |-4474-467d-b9bb-|
000000c0  64 36 30 36 63 61 64 31  32 61 62 64 00 00 00 00  |d606cad12abd....|
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001c0  2a 11 50 fd 0b 8a 05 b6  67 1a e5 2f 2b a7 de d5  |*.P.....g../+...|
000001d0  2c b3 17 7c a5 21 b5 a1  5a f3 86 5c 96 9e 16 c0  |,..|.!..Z..\....|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

如您所見，0x1c0/0x1d0 行中的數據與以前完全不同，所以如果運氣好的話，您的虛假分區表也將消失（在重新讀取分區表之後）。與此同時，這是值得關注的，因為未來對標題的任何更改都可能將其帶回……

我假設您使用的是 LUKS2，因為舊的 LUKS1 標頭不會在此偏移處儲存隨機數據，並且luksFormat還會像這樣將其歸零：

000001c0  00 00 de ad 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

所以這個問題甚至不應該出現在舊的 LUKS1 標頭格式中。

引用自：https://unix.stackexchange.com/questions/561745

相關問答

Mdadm

MDADM RAID1 創建 - 哪個設備是“主設備”？

  • October 11, 2020
檢視問答
Raid

mdadm 軟體突襲問題

  • September 10, 2019
檢視問答
Mdadm

mdadm raid1 和 4k 驅動器上的塊大小（或塊大小）？

  • July 19, 2014
檢視問答
Software-Raid

在高可用性軟體 RAID 1 伺服器上使用 smartd（在 smartmontools 中）監控磁碟執行狀況

  • April 1, 2014
檢視問答
Ext3

md raid1 ext3 和 4k 扇區因目錄操作而變慢

  • January 27, 2014
檢視問答
Centos

如何正確配置 mdadm.conf

  • May 26, 2022
檢視問答