收到錯誤“似乎有非常相似的超級塊”。有辦法解決嗎？
所以我的分區有些奇怪。
root@rescue ~ # mdadm -A --scan mdadm: WARNING /dev/sdb1 and /dev/sdb appear to have very similar superblocks. If they are really different, please --zero the superblock on one If they are the same or overlap, please remove one from the DEVICE list in mdadm.conf. root@rescue ~ # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 4G 1 loop sda 8:0 0 2.7T 0 disk ├─sda1 8:1 0 1G 0 part ├─sda2 8:2 0 64G 0 part ├─sda3 8:3 0 200G 0 part ├─sda4 8:4 0 1M 0 part └─sda5 8:5 0 2.5T 0 part sdb 8:16 0 2.7T 0 disk └─sdb1 8:17 0 2.7T 0 part sdc 8:32 0 223.6G 0 disk在突襲檢查中，我收到這樣的錯誤。有什麼辦法可以在不失去數據的情況下修復它？
PS 添加了新的輸出
root@rescue ~ # fdisk -l /dev/sdb Disk /dev/sdb: 2.7 TiB, 3000592982016 bytes, 5860533168 sectors Disk model: ST3000NM0033-9ZM Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: A93A2325-8454-A346-8133-2ACDF59BE163 Device Start End Sectors Size Type /dev/sdb1 2048 5860533134 5860531087 2.7T Linux RAID root@rescue ~ # mdadm --examine /dev/sdb /dev/sdb: Magic : a92b4efc Version : 0.90.00 UUID : 1ac1670b:7c95ed23:0028a58b:a51e25d4 Creation Time : Mon Dec 2 20:14:13 2019 Raid Level : raid0 Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Update Time : Mon Dec 2 20:14:13 2019 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Checksum : a194544e - correct Events : 1 Chunk Size : 8K Number Major Minor RaidDevice State this 1 8 17 1 active sync /dev/sdb1 0 0 8 5 0 active sync /dev/sda5 1 1 8 17 1 active sync /dev/sdb1 root@rescue ~ # mdadm --examine /dev/sdb1 /dev/sdb1: Magic : a92b4efc Version : 0.90.00 UUID : 1ac1670b:7c95ed23:0028a58b:a51e25d4 Creation Time : Mon Dec 2 20:14:13 2019 Raid Level : raid0 Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Update Time : Mon Dec 2 20:14:13 2019 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Checksum : a194544e - correct Events : 1 Chunk Size : 8K Number Major Minor RaidDevice State this 1 8 17 1 active sync /dev/sdb1 0 0 8 5 0 active sync /dev/sda5 1 1 8 17 1 active sync /dev/sdb1
這是舊 mdadm 0.90 元數據的一個非常常見的問題。此元數據位於設備末尾的某處，但不是在最後一個扇區，而是在 64K 對齊的偏移處：
超級塊的長度為 4K，並寫入一個 64K 對齊的塊中，該塊從設備末尾開始至少 64K 且小於 128K（即獲取超級塊的地址，將設備的大小四捨五入到 64K 的倍數和然後減去 64K）。
來源：https ://raid.wiki.kernel.org/index.php/RAID_superblock_formats#The_version-0.90_Superblock_Format
不幸的是，對於一個不是 64K 大的整個磁碟設備，並且有一個分區延伸到非常接近磁碟末尾（進入最後一個部分 64K 塊），它意味著最後一個分區的超級塊位置，以及超級塊位置對於整個驅動器，結果是完全相同的。
mdadm 手冊頁也提到了這個問題：
0, 0.90 Use the original 0.90 format superblock. This format limits arrays to 28 component devices and limits component devices of levels 1 and greater to 2 terabytes. It is also possible for there to be confusion about whether the superblock applies to a whole device or just the last partition, if that partition starts on a 64K boundary.Indirectly it also suggests another workaround: just don’t make the partition 64K-aligned; then the superblock on the partition won’t be 64K-aligned to the disk, and as such, it couldn’t be seen as superblock for the whole disk.
But in your case, your partition is MiB aligned which also makes it 64K aligned. The superblock position for the partition is
2048(start) + 5860531087(size) - 15(size%128) = 5860532992, the superblock position for the disk is5860533168(size) - 48(size%128) - 128 = 5860532992.In other words, you don’t have two superblocks here; it’s one and the same. If you
mdadm --zero-superblockone as the message suggested, you end up losing both. So please, don’t do that.Adding a DEVICE line in mdadm.conf is an easy workaround for one system, but once you boot a Live CD or Initramfs that doesn’t have your mdadm.conf, the problem just resurfaces.
This is one of several reasons why 0.90 metadata should be avoided. Use 1.x metadata instead.
mdadmallows converting from 0.90 to 1.0 metadata format, for example like this:mdadm --stop /dev/mdX mdadm --assemble /dev/mdX --update=metadata /dev/sdx1 /dev/sdy1From the manpage:
The metadata option only works on v0.90 metadata arrays and will convert them to v1.0 metadata. The array must not be dirty (i.e. it must not need a sync) and it must not have a write- intent bitmap.
Using the default 1.2 metadata (located at the start instead of end) would be even better, but it would require all data to be shifted and can’t be converted in-place.