惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

MyScale Blog
MyScale Blog
J
Java Code Geeks
Vercel News
Vercel News
A
About on SuperTechFans
G
Google Developers Blog
C
Check Point Blog
腾讯CDC
N
Netflix TechBlog - Medium
博客园 - 司徒正美
S
SegmentFault 最新的问题
D
DataBreaches.Net
博客园_首页
美团技术团队
Stack Overflow Blog
Stack Overflow Blog
博客园 - 聂微东
量子位
雷峰网
雷峰网
IT之家
IT之家
小众软件
小众软件
Blog — PlanetScale
Blog — PlanetScale
博客园 - 三生石上(FineUI控件)
H
Help Net Security
宝玉的分享
宝玉的分享
博客园 - 叶小钗

Allen Hua 的网络博客

由于 Linux 桌面没有一个好用的天气程序就写了一个跨平台的CheckitoutWeather 给 caesium-image-compressor 图片压缩程序构建了 Linux AppImage v2.8.5 最新版 debian13(debian trixie)安装了nvidia闭源驱动后从x11切换到wayland的方法 山间摩旅追风,偶遇一场绚烂晚霞 最近使用debian系统的一些心得 机械革命无界14Pro笔记本debian forky成功驱动内置扬声器和麦克风 记录 typecho 1.2.0 升级到 1.3.0 过程 开发了一款openwrt插件:文本剪贴板 解决机械革命笔记本内屏高刷240Hz闪屏问题 使用 Java 写了一个局域网端口扫描器 - Allen Hua 的网络博客 openwrt使用外置根extroot机制扩展根分区大小 - Allen Hua 的网络博客 将机场ss节点批量转换成ss字符串链接批量添加到passwall - Allen Hua 的网络博客 给机械革命钛钽plus换屏:NY2换成NZ2 - Allen Hua 的网络博客 记录一次pve宿主机和上面的debian虚机无故down机事件 - Allen Hua 的网络博客 给图床部署cdn腾讯云的edgeone并排查Cache-Control max-age 3600的问题 - Allen Hua 的网络博客 从高山草甸到徽派古村:武功山反穿与皖浙赣自驾行记 - Allen Hua 的网络博客 增程器就是充电宝?别被忽悠了 - Allen Hua 的网络博客 浦口龙虎巷扫街,记录人间真实 博客图片压缩方案更新|AVIF|WebP|MozJPEG|标准JPEG Windows 电脑使用 Obs Studio 录制各个网站视频/桌面画面教程 为typecho博客添加latex支持 新能源汽车之纯电车使用交流慢充和直流快充的充电损耗对比 2025年3月更新全国5A景区名录 2025最新查看小米/红米手机电池健康度和循环次数方法 完美解决 seafile FILE_SERVER_ROOT 配置导致的内网外网不能同时访问和上传下载的问题 纯css实现typecho博客文章文字spoiler剧透效果 我对Typecho Facile主题的一些修改,图片懒加载优化,样式定制 2024年8月我的宜昌 - 重庆 - 川西小环线自驾旅行分享 2022年打卡南京市区人防工程纳凉点 2024年带着A7C2+腾龙28-200 再次来到红山森林动物园
修复一块 18 年 12 月买的二手 4TB 机械硬盘
Allen Hua · 2024-01-17 · via Allen Hua 的网络博客
阅读量:2474

warning: 这篇文章距离上次修改已过860天,其中的内容可能已经有所变动。

18 年开始自组软路由的硬件,后面入了 PT 的坑,在 18 年 12 月购买了一块二手 4TB 机械硬盘。

18年12月购买的二手机械硬盘.jpg

这 5 年多,我的软路由一直比较稳定的运行着,期间有过几次因为二手电源而淘气,后面换了一个全新的长城 200w 电源解决。

但是这块硬盘也没有让人省心,除了日常读取它上面的数据时能清晰的感受到里面磁头开始转动的声音,有时候写大量数据还产生豆子沙沙的声音。

而且有过好多次因为硬盘问题导致 OpenWrt 系统无法启动。

最近这块磁盘“掉盘”了,看了一下 OpenWrt 上有硬件设备,但是无法挂载到挂载点。里面还有以前存储的所有照片和视频,虽然这些照片和视频都被我备份到了我 immich server 上,但是缺少一份文件冷备份。

今天就试图修复这块盘,让它重新在 OpenWrt 上恢复读写能力。

磁盘分区 /dev/sdb1 无法挂载到 mount point /mnt/ThreeTB

lsblk 缺失挂载点 挂载失败.jpg

使用 df 检查,确实没有挂载成功

[root@dk-router:10:44 AM /mnt/ThreeTB] # df -hT

Filesystem Type Size Used Available Use% Mounted on

/dev/root squashfs 64.8M 64.8M 0 100% /rom

tmpfs tmpfs 1.9G 26.3M 1.9G 1% /tmp

/dev/loop0 f2fs 445.4M 175.2M 270.2M 39% /overlay

overlayfs:/overlay overlay 445.4M 175.2M 270.2M 39% /

/dev/sdc1 ext4 15.7M 12.0K 15.4M 0% /boot

/dev/sdc1 ext4 15.7M 12.0K 15.4M 0% /boot

tmpfs tmpfs 512.0K 0 512.0K 0% /dev

/dev/sda1 ext4 3.6T 211.6G 3.2T 6% /mnt/four

/dev/sdd1 ext4 457.4G 193.5G 240.6G 45% /mnt/FiveOO

/dev/sde1 ext4 2.7T 2.4T 108.9G 96% /mnt/ThreeTB2

/dev/sdc1 ext4 15.7M 12.0K 15.4M 0% /mnt/sdc1

使用 smartctl 查看硬盘健康状态,居然是 PASSED,说明还能挣扎一下 😏️

[root@dk-router:10:45 AM /mnt/ThreeTB] # smartctl -H /dev/sdb1

smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.15.58] (localbuild)

Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===

SMART overall-health self-assessment test result: PASSED

使用 fsck 检查时,确保磁盘设备没有挂载上。求稳还是执行一下 umount /dev/sdb1

[root@dk-router:10:56 AM /mnt/ThreeTB] # fsck.ext

fsck.ext2 fsck.ext3 fsck.ext4

[root@dk-router:10:56 AM /mnt/ThreeTB] # fsck.ext

fsck.ext2 fsck.ext3 fsck.ext4

[root@dk-router:10:56 AM /mnt/ThreeTB] # umount /dev/sdb1

umount: /dev/sdb1: not mounted.

因为磁盘文件系统格式是 ext4,所以使用 fsck.ext4 /dev/sdb1 命令

[root@dk-router:10:59 AM /mnt/ThreeTB] # fsck.ext4 /dev/sdb1

e2fsck 1.46.5 (30-Dec-2021)

/dev/sdb1: recovering journal

Error reading block 365987992 (I/O error). Ignore error<y>? yes

Force rewrite<y>? yes

JBD2: Invalid checksum recovering data block 524812391 in log

JBD2: Invalid checksum recovering data block 524291104 in log

JBD2: Invalid checksum recovering data block 524812399 in log

JBD2: Invalid checksum recovering data block 525338144 in log

JBD2: Invalid checksum recovering data block 524812385 in log

JBD2: Invalid checksum recovering data block 524812395 in log

JBD2: Invalid checksum recovering data block 524812389 in log

JBD2: Invalid checksum recovering data block 524815392 in log

JBD2: Invalid checksum recovering data block 524812392 in log

JBD2: Invalid checksum recovering data block 524812384 in log

JBD2: Invalid checksum recovering data block 524813344 in log

JBD2: Invalid checksum recovering data block 524812408 in log

JBD2: Invalid checksum recovering data block 524812383 in log

JBD2: Invalid checksum recovering data block 702552096 in log

JBD2: Invalid checksum recovering data block 524812401 in log

JBD2: Invalid checksum recovering data block 524812407 in log

JBD2: Invalid checksum recovering data block 702552608 in log

JBD2: Invalid checksum recovering data block 524812403 in log

JBD2: Invalid checksum recovering data block 524814880 in log

JBD2: Invalid checksum recovering data block 524812398 in log

JBD2: Invalid checksum recovering data block 524812397 in log

JBD2: Invalid checksum recovering data block 524812393 in log

JBD2: Invalid checksum recovering data block 524292128 in log

JBD2: Invalid checksum recovering data block 524288095 in log

JBD2: Invalid checksum recovering data block 524288097 in log

JBD2: Invalid checksum recovering data block 524288096 in log

JBD2: Invalid checksum recovering data block 524812388 in log

JBD2: Invalid checksum recovering data block 525336608 in log

JBD2: Invalid checksum recovering data block 524812406 in log

JBD2: Invalid checksum recovering data block 524812402 in log

JBD2: Invalid checksum recovering data block 524812404 in log

JBD2: Invalid checksum recovering data block 524291616 in log

JBD2: Invalid checksum recovering data block 524812386 in log

JBD2: Invalid checksum recovering data block 524812409 in log

JBD2: Invalid checksum recovering data block 524817952 in log

JBD2: Invalid checksum recovering data block 524812387 in log

JBD2: Invalid checksum recovering data block 524816416 in log

JBD2: Invalid checksum recovering data block 524819488 in log

JBD2: Invalid checksum recovering data block 524812396 in log

JBD2: Invalid checksum recovering data block 524292640 in log

JBD2: Invalid checksum recovering data block 524818464 in log

JBD2: Invalid checksum recovering data block 524818976 in log

JBD2: Invalid checksum recovering data block 524289056 in log

JBD2: Invalid checksum recovering data block 524812832 in log

JBD2: Invalid checksum recovering data block 524288094 in log

JBD2: Invalid checksum recovering data block 524812411 in log

JBD2: Invalid checksum recovering data block 524290592 in log

JBD2: Invalid checksum recovering data block 524293152 in log

JBD2: Invalid checksum recovering data block 524293664 in log

JBD2: Invalid checksum recovering data block 524295712 in log

JBD2: Invalid checksum recovering data block 524820000 in log

JBD2: Invalid checksum recovering data block 525338656 in log

JBD2: Invalid checksum recovering data block 524812394 in log

JBD2: Invalid checksum recovering data block 524813856 in log

JBD2: Invalid checksum recovering data block 524289568 in log

JBD2: Invalid checksum recovering data block 524290080 in log

JBD2: Invalid checksum recovering data block 524814368 in log

JBD2: Invalid checksum recovering data block 524815904 in log

JBD2: Invalid checksum recovering data block 524295200 in log

JBD2: Invalid checksum recovering data block 525337632 in log

Journal checksum error found in /dev/sdb1

/dev/sdb1 contains a file system with errors, check forced.

Pass 1: Checking inodes, blocks, and sizes

Inode 131072602 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131072627 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131072974 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131072986 extent tree (at level 2) could be narrower. Optimize<y>? yes

Inode 131073020 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131073033 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131073054 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131073057 extent tree (at level 1) could be narrower. Optimize ('a' enables 'yes' to all) <y>? yes

Inode 131073077 extent tree (at level 1) could be narrower. Optimize ('a' enables 'yes' to all) <y>? yes

Inode 131073095 extent tree (at level 1) could be narrower. Optimize ('a' enables 'yes' to all) <y>? yes

Inode 131073107 extent tree (at level 1) could be narrower. Optimize ('a' enables 'yes' to all) <y>? yes

Inode 131073113 extent tree (at level 2) could be narrower. Optimize<y>? yes

Inode 131073126 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131073129 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131203700 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131204106 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131204124 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131204136 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131204142 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131204198 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131204208 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131204279 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131204285 extent tree (at level 2) could be narrower. Optimize<y>? yes

Inode 131204295 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131204346 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131204355 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131204371 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131204393 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131204405 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131204413 extent tree (at level 2) could be narrower. Optimize<y>? yes

Inode 131204415 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131204435 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131204453 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131204457 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131204471 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131204483 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131204489 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131204558 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131204655 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131204666 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131204667 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131334149 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 131334152 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 132908866 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 132908867 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 132908902 extent tree (at level 2) could be narrower. Optimize<y>? yes

Inode 132909521 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 132909755 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 132910044 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 132910190 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 132910212 extent tree (at level 2) could be narrower. Optimize<y>? yes

Inode 132910341 extent tree (at level 1) could be narrower. Optimize<y>? yes

Inode 132910363 extent tree (at level 1) could be narrower. Optimize<y>? yes

Pass 1E: Optimizing extent trees

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

/lost+found not found. Create<y>? yes

Pass 4: Checking reference counts

Pass 5: Checking group summary information

/dev/sdb1: ** FILE SYSTEM WAS MODIFIED **

/dev/sdb1: 47029/183148544 files (2.7% non-contiguous), 666008011/732566385 blocks

跟着终端操作输入 y 即可

最后那段日志,说明

fsck.ext4 命令完成了对文件系统的修复过程。每个步骤的解释:(来自 ChatGPT)

  • Pass 1E: 优化范围树(extent trees):这个步骤优化了文件系统中的范围树结构,以提高性能和效率。
  • Pass 2: 检查目录结构:这个步骤检查文件系统中的目录结构是否正确,确保文件和目录的层次结构正确无误。
  • Pass 3: 检查目录连通性:这个步骤检查文件系统中的目录之间的连接是否正确,确保文件和目录之间的关联关系正确无误。
  • /lost+found 未找到。创建? yes:这个步骤是在文件系统中创建一个 /lost+found 目录,用于存放在修复过程中找到的孤立文件或目录。
  • Pass 4: 检查引用计数:这个步骤检查文件系统中文件和目录的引用计数,确保每个文件和目录都有正确的引用计数。
  • Pass 5: 检查组摘要信息:这个步骤检查文件系统中每个组的摘要信息,确保文件系统的整体状态正确无误。
  • /dev/sdb1: 文件系统已被修改 :这个提示表示文件系统已经被修改,意味着 fsck.ext4 命令成功修复了文件系统中的问题。
  • /dev/sdb1: 47029/183148544 个文件(2.7% 非连续),666008011/732566385 个块:这个提示提供了修复后文件系统的统计信息,包括修复的文件数量、非连续文件的百分比以及修复的块数量。

综上所述,您的文件系统已经成功修复,并且修复后的文件系统处于可用状态。

然后通过 OpenWrt luci 界面重启了挂载点服务,url 路径是 luci/admin/system/mounts

挂载成功!开心

修复后挂载成功.jpg

再通过 samba 看到了以前备份的这些照片视频文件,看着往日用摄像头记录下的回忆,很感动。

这些照片找了回来 虽然上传到 immich 了 但是缺失一份冷备份.jpg

之前把我 23 年 618 购买的机械革命无界 14 pro 加装了一块致态 tiplus 7100 2TB m2 固态,之前安装了 deepin,时隔半年多,我决定重新装上 debian12,也装上 DE 环境,但是大部分场景作为服务器使用。

在我装上 debian 12 之后,立马使用 nfs 连上 OpenWrt 上的这块磁盘开启的 nfs 服务,通过 rsync 把这些照片视频冷备份到了 致态 tiplus 7100 固态硬盘上面。

安心了,很爽快。因为这块固态性能还不错,我在手机上使用 Solid Explorer 或者 mac 上通过腾讯看图浏览里面的照片和视频,速度上明显快了 n 个数量级。还是固态香啊。

这块机械硬盘修复成功,存储占的满是因为里面放了好几年前下载的 imdb top 250,这个我记得就有 2.x TB 了。

好了就这些了,如果你对文中所描述的任何事物感兴趣,欢迎和我讨论。