因此,由于各种原因,我最终得到了一个 45TB 的单 Linux 逻辑卷,没有分区表,格式化为 NTFS,包含 28TB 的数据(文件系统本身是 28TB)。
该文件系统是在 Linux 中创建的,并且可由 Linux 安装。当我尝试在同一台机器上基于 KVM 的 Windows VM 中安装它时,问题出现了。Windows 看不到 28TB 的文件系统,而是一个 1.8TB 的磁盘,其中包含一些随机大小的无用分区。
我推测这是因为 Windows 正尝试将真实 NTFS 文件系统数据的前几个字节读取为分区表。
我看到了针对该问题的一些可能的解决方案,但不知道如何实际执行其中任何一个:
- Windows 是否已将未分区的磁盘(单个卷)读取为文件系统?
- 如何以某种方式在此逻辑卷上生成分区表而不破坏文件系统本身所保存的数据?
- 以某种方式伪造一个分区表,指向 LVM 卷并将其导出到 KVM 客户机(在 libvirt 中运行)
parted 报告的当前“分区表”是:
Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/chandos--dh-data: 48.0TB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Number Start End Size File system Flags
1 0.00B 48.0TB 48.0TB ntfs
答案1
我遇到过类似的问题,我意外地对分区而不是磁盘进行了映像处理。映像是通过网络复制的,我没有时间再次复制它们。然而,它们比 28TB 小得多,我使用了一个需要复制映像的过程。
初始图像是使用以下方法拍摄的:
dd if=/dev/sda1 of=/image.bin
为了添加分区表,无需通过网络复制所有内容,我仅将 MBR 复制到一个文件中。
dd if=/dev/sda of=/mbr.bin bs=512 count=1
然后,我添加了 mbr 并复制了数据。
fdisk -l /mbr.bin
# take the start position * units in bytes (ex start at 256 * units of 512 bytes = 131072 bytes)
truncate -s (disk size in bytes + number of above) /newfile.bin
dd if=/mbr.bin of=/newfile.bin
dd if=/image.bin of=/newfile.bin oflag=seek_bytes seek=(number from above)
一旦完成,/newfile.bin
就有完整的分区表+数据。
答案2
我实际上还没有找到一个好的解决方案。幸运的是,还有另一个驱动器架,有大约 30TB 的空间,我可以用它迁移到新分区的卷。这需要很长时间,但应该可以。
有人建议,可以用Linux 设备映射器(创建一个虚拟设备,从文件中映射一个假的 GPT 分区表,以及 LVM 逻辑卷),但我会把这个问题留给更聪明的人去解决。
编辑:最后写出了一个解决方案这里
答案3
超过 2TB 的磁盘需要使用 GPT 分区表。对于 <2TB 的磁盘,MBR 就足够了。