☰

ext4 磁盘已完全卸载，但 fsck.ext4 声称未卸载并发现错误

tag-icon • tag-icon linux ubuntu-16.04 ext4
ext4 磁盘已完全卸载，但 fsck.ext4 声称未卸载并发现错误

我买了一块（新的）8TB SATA 硬盘，用来备份我的 Ubuntu 16.04 数据盘。它通过 Technet USB3 扩展坞连接到我的盒子（我以前用过，没有遇到过问题）。

我的备份脚本基本上

/sbin/mkfs.ext4 -c  /dev/sdg1
mount /dev/sdg1 /mnt/backup
mkdir -p /mnt/backup/data1
cp -a /my-pool/my-data1/* /mnt/backup/data1
mkdir -p /mnt/backup/data2
cp -a /my-pool/my-data2/* /mnt/backup/data2
umount /dev/sdg1

这次我在对磁盘进行分区后单独运行了 mkfs，而不是将其作为脚本的一部分。mkfs 说它在格式化文件系统时使用的是 4K 块。与我用 ext3 格式化较小的驱动器相比，它似乎完成得相当快

这将从 ZFS 文件系统 data1 和 data2 复制大约 4.5Tb 的数据。此过程中没有显示任何错误。

由于这是一个新磁盘，我想我会有点偏执，并针对 /dev/sdg1 运行 /sbin/fsck.ext4，期望一切都会好起来。然而，fsck 抱怨磁盘没有完全卸载（即使它已经卸载，并且系统一直处于开机状态），然后继续发现大量错误。我厌倦了手动响应，所以我退出了 fsck，并以 /sbin/fsck.ext4 -y /dev/sdg1 的形式重新运行，fsck 发现了数百个错误（多重声明块、校验和和其他错误，在 fsck 填满终端历史记录之前我没能记下来）。

这是否意味着硬盘本身可能有问题或者有其他解释？

我的理解是 umount 应该强制写入任何待处理的块，所以我不明白为什么 fsck 会声称驱动器未干净地卸载。

ext4 和大容量驱动器是否存在一些特殊的陷阱或者我可能做错了什么？

File ??? (inode #85393418, mod time Thu Jul 20 08:01:35 2017) 
  has 1 multiply-claimed block(s), shared with 1 file(s):
    ... (inode #208650243, mod time Tue Dec 24 21:15:08 2097)
Clone multiply-claimed blocks? yes

File ??? (inode #85393421, mod time Thu Jul 20 07:58:56 2017) 
  has 1 multiply-claimed block(s), shared with 1 file(s):
    ... (inode #208650243, mod time Tue Dec 24 21:15:08 2097)
Clone multiply-claimed blocks? yes

File ??? (inode #85393422, mod time Thu Jul 20 07:59:38 2017) 
  has 3 multiply-claimed block(s), shared with 2 file(s):
    ... (inode #208650243, mod time Tue Dec 24 21:15:08 2097)
    ... (inode #211472387, mod time Sat Jul 15 23:06:03 2056)
Clone multiply-claimed blocks? yes

File ??? (inode #85393423, mod time Thu Jul 20 07:58:28 2017) 
  has 3 multiply-claimed block(s), shared with 1 file(s):
    ... (inode #208650243, mod time Tue Dec 24 21:15:08 2097)
Clone multiply-claimed blocks? yes

同样奇怪的是，在我查看过的所有错误中都出现了相同的 inode（208650243）。

更新：fsck.ext4 仍在运行！我让它继续运行，因为我觉得它至少有机会完成并给我留下一个有用的文件系统，但它已经运行了 16 多个小时。

UPDATE2：我原以为这可能是因为我在 jbd2 完成创建所有日志结构之前就开始使用驱动器了（这显然是懒惰发生的，请参阅https://askubuntu.com/questions/119742/ext4-jbd2-journaling-active-even-on-empty-filesystem）。我清除了现有的分区表，创建了一个新分区，然后等待了大约 6 个小时，直到 jbd2 似乎停止写入磁盘。然后我使用 rsync 备份文件系统。一切似乎都很好。我等了一个小时左右，然后使用 umount 卸载了设备。但是当我尝试重新安装它时出现了同样的错误：

mount: mount /dev/sdg1 on /mnt/bdavepool failed: Structure needs cleaning

答案1

鉴于新磁盘设置了 GPT 分区表，最可能的答案似乎是磁盘有故障。

我已经订购了新磁盘，将再次尝试。一旦我确认更换的磁盘是否存在问题，就会更新此答案。

更新 2020/5/20 这个问题实际上似乎不是驱动器本身的问题，而是使用 USB3 驱动器托架将大量数据写入磁盘的问题。我将驱动器托架换成了带有 SATA 接口的无托架驱动器托架，从那以后，我在备份磁盘时再也没有遇到过这种情况。

相关内容