[已解决]强制关闭电源后，貌似硬盘坏了，无法再重新安装系统，如何解决呢？

HIDE · 2020-09-30 12:08:10

在工作时，突然系统就卡死动不了了，在等待了20分钟后，最后决定强制关闭电源重新打开电脑。就发现进不去了系统了，fsck也修复不了。然后我就决定格式化掉根分区，重新安装系统吧，反正正好想换成btrfs试一试。然而一切顺利，安装完系统后，一次重启就再也进不去了。我用安装系统的U盘进入想尝试mount一下，发现已经mount不了了。下面是我用一些工具的log，这个是硬盘那个扇区有问题了么？我该如何解决呢？如有帮助，感谢万分！

# fsck /dev/nvme0n1p5
fsck from util-linux 2.35.2
If you wish to check the consistency of a BTRFS filesystem or
repair a damaged filesystem, see btrfs(8) subcommand 'check'.

# btrfs check /dev/nvme0n1p5
Opening filesystem to check...
[ 1006.199126] blk_update_request: critical medium error, dev nvme0n1, sector 255894496 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0
[ 1006.205371] blk_update_request: critical medium error, dev nvme0n1, sector 255894496 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 1006.207147] Buffer I/O error on dev nvme0n1p5, logical block 530556, async page read
[ 1006.210355] blk_update_request: critical medium error, dev nvme0n1, sector 255894496 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 1006.212298] Buffer I/O error on dev nvme0n1p5, logical block 530556, async page read
bad tree block 2173157376, bytenr mismatch, want=2173157376, have=0
Couldn't setup device tree
ERROR: cannot open file system

最近编辑记录 HIDE (2020-10-16 09:41:39)

依云 · 2020-09-30 13:55:08

看一下 smartctl 的信息？

HIDE · 2020-10-09 12:02:06

依云说：

看一下 smartctl 的信息？

smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.7.6-arch1-1] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:                       WDC PC SN520 SDAPMUW-256G-1001
Serial Number:                      193654802964
Firmware Version:                   20240001
PCI Vendor/Subsystem ID:            0x15b7
IEEE OUI Identifier:                0x001b44
Total NVM Capacity:                 256,060,514,304 [256 GB]
Unallocated NVM Capacity:           0
Controller ID:                      1
Number of Namespaces:               1
Namespace 1 Size/Capacity:          256,060,514,304 [256 GB]
Namespace 1 Formatted LBA Size:     512
Namespace 1 IEEE EUI-64:            001b44 8b44278b21
Local Time is:                      Fri Oct  9 03:58:38 2020 UTC
Firmware Updates (0x14):            2 Slots, no Reset required
Optional Admin Commands (0x0017):   Security Format Frmw_DL Self_Test
Optional NVM Commands (0x001f):     Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat
Maximum Data Transfer Size:         128 Pages
Warning  Comp. Temp. Threshold:     82 Celsius
Critical Comp. Temp. Threshold:     86 Celsius
Namespace 1 Features (0x02):        NA_Fields

Supported Power States
St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +     2.60W       -        -    0  0  0  0        0       0
 1 +     2.60W       -        -    1  1  1  1        0       0
 2 +     1.70W       -        -    2  2  2  2        0       0
 3 -   0.0250W       -        -    3  3  3  3     5000    9000
 4 -   0.0025W       -        -    4  4  4  4     5000   44000

Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 +     512       0         2
 1 -    4096       0         1

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!
- NVM subsystem reliability has been degraded

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x04
Temperature:                        39 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%
Data Units Read:                    3,443,798 [1.76 TB]
Data Units Written:                 1,031,301 [528 GB]
Host Read Commands:                 41,503,323
Host Write Commands:                11,405,502
Controller Busy Time:               72
Power Cycles:                       304
Power On Hours:                     159
Unsafe Shutdowns:                   43
Media and Data Integrity Errors:    2,015
Error Information Log Entries:      2,015
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0

Error Information (NVMe Log 0x01, max 256 entries)
No Errors Logged

依云 · 2020-10-09 12:19:06

确实出错了，但是你使用得并不是很多呀。所以：

1. 你是否有用 fstrim，或者开启文件系统的 discard 选项？（你这块盘上都有些啥？）
2. 你这块盘上总共占用了多少数据？不是说你装系统的这个分区，是所有分区。

我怀疑你的 SSD 写入过满，导致写入不均匀，某些块被写太多次了。

HIDE · 2020-10-09 13:08:08

依云说：

确实出错了，但是你使用得并不是很多呀。所以：
1. 你是否有用 fstrim，或者开启文件系统的 discard 选项？（你这块盘上都有些啥？）
2. 你这块盘上总共占用了多少数据？不是说你装系统的这个分区，是所有分区。
我怀疑你的 SSD 写入过满，导致写入不均匀，某些块被写太多次了。

没有哎，fstrim和文件系统的 discard 选项是什么我都不知道。没用过。我现在这个是固态硬盘来的。我在上面主要分了两个分区，一个是windows的系统分区；一个是Linux的系统分区，现在这个没有内容。所以现在就存放Windows分区的有比较多内容吧。大概40G。我平时都是上Linux的，很少会启动Windows来用，这个系统我就是放着做备用的。
那我应该怎么做呢，做分区的时候跳过坏的部分么。
FluxBB bbcode 测试
我用一些扫描磁盘的软件，可以发现这个。

依云 · 2020-10-09 13:27:59

那看来你就是没用 fstrim 的锅。去把不想删掉的分区，能挂载的都挂载上，然后对着挂载点 fstrim 一下。然后对着要装系统的空分区跑一下 blkdiscard。
SSD 跟机械硬盘不一样，它使用的是逻辑地址，具体映射到哪个物理块是主控来决定的。当空闲块够多的时候，SSD 就能尽量让写入均匀，不会逮着一小部分块一直写。
Windows 应该会自动对删除操作进行 discard 操作，但是 Arch Linux 默认不会。推荐的方案是使用 fstrim.timer 来定期跑一遍，而不是一有删除就跟主控说一声。

primes · 2020-10-09 16:58:17

依云说：

那看来你就是没用 fstrim 的锅。去把不想删掉的分区，能挂载的都挂载上，然后对着挂载点 fstrim 一下。然后对着要装系统的空分区跑一下 blkdiscard。
SSD 跟机械硬盘不一样，它使用的是逻辑地址，具体映射到哪个物理块是主控来决定的。当空闲块够多的时候，SSD 就能尽量让写入均匀，不会逮着一小部分块一直写。
Windows 应该会自动对删除操作进行 discard 操作，但是 Arch Linux 默认不会。推荐的方案是使用 fstrim.timer 来定期跑一遍，而不是一有删除就跟主控说一声。

你怎么什么都知道?
还好有事没有事来瞅瞅,不然都不知道有fstrim这个东东!一下引出来这么多固态的知识!
吓的我今晚一定要把本子上的manjaro fstrim一下!!!

最近编辑记录 primes (2020-10-09 16:59:04)

Mr.I · 2020-10-09 22:29:31

primes 说：

你怎么什么都知道?

像依云和凤凰这样的前辈，在受过良好专业教育的基础上，以正确的学习方式学习了十几年或是更久。在她们创建 Archlinux 中文社区的时候，我甚至都不知道什么是 Linux 什么是 GNU。
对于我们这些后来之人，学好计算机科学相关的基础知识，日常积累 GNU/Linux 的使用经验和编程经验，总有一天也可以达到被人说 “你怎么什么都知道？” 的程度。

依云 · 2020-10-09 23:27:37

要不是用不上+电路没学好，我还会记得 SSD 记录数据的原理呢。关于 SSD 的信息我主要是从 UEFI和BIOS探秘这里知道的。
我不过是把别人用来看动漫、电视剧和打游戏的时间花在看科普、读文档上罢了。
fstrim 这个 ArchWiki 上有讲的。

对了，使用 fstrim 要注意一个事儿：不指定 trim 什么的时候，它会把所有挂载了的能 trim 的文件系统全部给 trim 了。这包括了位于机械硬盘上的、已经通过 loop 设备挂载了的文件系统镜像。这类文件，一般创建的时候都是尽量连续分配的，trim 会把未使用的部分释放出来，于是文件会被打散，变得有越来越多的碎片。而另一方面，如果你的虚拟机硬盘文件嫌大，可以让虚拟机软件标记为 SSD 设备，然后进去 trim 一下，这样就能释放那些存有已删除数据的部分了。

primes · 2020-10-11 09:51:47

依云说：

对了，使用 fstrim 要注意一个事儿：不指定 trim 什么的时候，它会把所有挂载了的能 trim 的文件系统全部给 trim 了。这包括了位于机械硬盘上的、已经通过 loop 设备挂载了的文件系统镜像。这类文件，一般创建的时候都是尽量连续分配的，trim 会把未使用的部分释放出来，于是文件会被打散，变得有越来越多的碎片。而另一方面，如果你的虚拟机硬盘文件嫌大，可以让虚拟机软件标记为 SSD 设备，然后进去 trim 一下，这样就能释放那些存有已删除数据的部分了。

嗯嗯!!!thinks提醒!!!

HIDE · 2020-10-14 19:11:43

依云说：

那看来你就是没用 fstrim 的锅。去把不想删掉的分区，能挂载的都挂载上，然后对着挂载点 fstrim 一下。然后对着要装系统的空分区跑一下 blkdiscard。
SSD 跟机械硬盘不一样，它使用的是逻辑地址，具体映射到哪个物理块是主控来决定的。当空闲块够多的时候，SSD 就能尽量让写入均匀，不会逮着一小部分块一直写。
Windows 应该会自动对删除操作进行 discard 操作，但是 Arch Linux 默认不会。推荐的方案是使用 fstrim.timer 来定期跑一遍，而不是一有删除就跟主控说一声。

好的，非常感谢。我去了解了一下这些东西。我blkdiscard之后应该重新格式化分区为对应的文件系统吧。

依云 · 2020-10-14 19:50:43

HIDE 说：

好的，非常感谢。我去了解了一下这些东西。我blkdiscard之后应该重新格式化分区为对应的文件系统吧。

对呀。blkdiscard 之后这个块设备（分区）上就完全没数据啦。

Arch Linux

#1 2020-09-30 12:08:10

[已解决]强制关闭电源后，貌似硬盘坏了，无法再重新安装系统，如何解决呢？

#2 2020-09-30 13:55:08

Re: [已解决]强制关闭电源后，貌似硬盘坏了，无法再重新安装系统，如何解决呢？

#3 2020-10-09 12:02:06

Re: [已解决]强制关闭电源后，貌似硬盘坏了，无法再重新安装系统，如何解决呢？

#4 2020-10-09 12:19:06

Re: [已解决]强制关闭电源后，貌似硬盘坏了，无法再重新安装系统，如何解决呢？

#5 2020-10-09 13:08:08

Re: [已解决]强制关闭电源后，貌似硬盘坏了，无法再重新安装系统，如何解决呢？

#6 2020-10-09 13:27:59

Re: [已解决]强制关闭电源后，貌似硬盘坏了，无法再重新安装系统，如何解决呢？

#7 2020-10-09 16:58:17

Re: [已解决]强制关闭电源后，貌似硬盘坏了，无法再重新安装系统，如何解决呢？

#8 2020-10-09 22:29:31

Re: [已解决]强制关闭电源后，貌似硬盘坏了，无法再重新安装系统，如何解决呢？

#9 2020-10-09 23:27:37

Re: [已解决]强制关闭电源后，貌似硬盘坏了，无法再重新安装系统，如何解决呢？

#10 2020-10-11 09:51:47

Re: [已解决]强制关闭电源后，貌似硬盘坏了，无法再重新安装系统，如何解决呢？

#11 2020-10-14 19:11:43

Re: [已解决]强制关闭电源后，貌似硬盘坏了，无法再重新安装系统，如何解决呢？

#12 2020-10-14 19:50:43

Re: [已解决]强制关闭电源后，貌似硬盘坏了，无法再重新安装系统，如何解决呢？

页脚