我有 2TB ext4 分区，上面有 50 万个文件。
我想检查这个分区是否包含任何错误。
我不想搜索坏块，只应该检查逻辑结构。
我已卸载分区并运行fsck /dev/sda2，但 fsck 立即返回退出代码 0，而无需实际检查整个文件系统。
我预计完整的分区检查需要几个小时才能完成。
我已阅读man fsck但没有找到“彻底测试”的选项。
我担心我的分区可能有一些扇区被垃圾数据意外覆盖。
我的硬盘以前连接到另一个操作系统，ext4 分区可能会因该操作系统的错误行为而受到损害。
这就是为什么我要确保整个树结构是完全正确的。
换句话说，我想执行类似于实用程序chkdsk.exe在 Windows 上所做的检查。
我应该在 Debian 上使用什么来完全检查 ext4 文件系统？
我有一个微型 SD 卡，它有一个 FAT32 分区和一个 EXT4 分区。EXT4 分区将不再挂载。dmesg 显示以下错误：
EXT4-fs (sdb2): bad geometry: block count 2199023779840 exceeds size of device (524288 blocks)
我用谷歌搜索过，但仍然不完全理解问题出在哪里（在分区表中？文件系统中？）也不知道如何解决它。我尝试了多种解决方案：
fsck.ext4 -b 163840 -B 4096 /dev/sdb2fsck -cc检查坏块The combination of flex_bg and !resize_inode features is not supported by resize2fs.当我运行 fsck 时，它出现了一堆错误（下面的完整输出），它声称已修复。但是，如果我再次运行它，它每次都会再次显示相同的错误。
如何修复错误的几何问题并使我的文件系统再次可挂载？这怎么发生的？
fsck 输出：
e2fsck 1.42 (29-Nov-2011)
One or more block group descriptor checksums are invalid. Fix<y>? yes
Group descriptor 0 checksum is invalid. FIXED.
Group …如何设置systemd为fsck崩溃后自动强制磁盘（硬关机）？
当我使用sysvinit（在 Arch Linux 中）时，/sbin/init我使用了 hack：在rc.local我创建的/forcefsck文件中；在rc.local.shutdown我删除它。在启动时rc.sysinit启用强制 fsck（如果/forcefsck存在）。
如何做同样的事情systemd？也许它有内置的自动fsck后粉碎设施？
我正在使用一个系统，我们希望允许用户根据需要随意调整日期和时间，并且可以随意重新启动。这很好，除了一件事：如果向后跳的时间很长，重新启动时会出现以下错误：
Checking filesystems
IMAGE2: Superblock last mount time (Tue Mar 1 17:32:48 2011,
now = Thu Feb 24 17:34:29 2011) is in the future.
IMAGE2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
...然后引导挂起等待用户控制台输入，即使获得控制台访问权限，也需要 root 密码才能继续。
这显然不太理想。有没有办法跳过检查或强制检查在重新启动时自动发生？
谷歌只提供了需要手动运行 fsck 的帮助，如果/当它被击中时，这不是我所追求的。设置时间后手动运行 fsck 不起作用，因为此时文件系统仍处于挂载状态，并且完全禁用 fsck 不太理想。
我正在使用红帽 6。
更新：我目前使用的解决方案是破解 fstab 以禁用重新启动时的 fsck 检查。我曾尝试使用 …
在基于 SD 卡的设备不正常关机后，我将 SD 卡取出到fsck根文件系统。这导致了以下变化：
e2fsck 1.43.1 (08-Jun-2016)
/dev/sdc2: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Run journal anyway<y>? no
Clear journal<y>? no
e2fsck: unable to set superblock flags on /dev/sdc2
在这里，我两次都回答“否”，但没有一系列是/否不会立即导致相同的结果。
文件系统可以挂载，随便检查一下就可以了；它在设备中也能正常工作，这就是根文件系统（实际上结果不太好，请参阅评论；tldr 一些无法挽回的损坏目录）。
我dd将分区（8 GB）分配给一个文件，并在其上尝试了 fsck。有趣的是：
e2fsck 1.43.1 (08-Jun-2016)
plush.rootfs: recovering journal
Clearing orphaned inode 18290 (uid=0, gid=0, mode=0100644, size=34096)
Clearing orphaned inode 18270 (uid=0, gid=0, mode=0100644, size=38916)
Clearing orphaned inode 18250 (uid=0, gid=0, mode=0100644, size=1128076)
Clearing orphaned inode 11411 (uid=0, …我正在阅读一篇关于文件系统修复的博客文章，作者提出了一个很好的问题......fsck -p应该在没有人工干预的情况下自动修复小错误。但是当它被告知整理文件系统时，它究竟会修复什么？它会修复什么错误，什么会导致它停止并告诉用户他或她必须以交互方式运行 fsck？是否有某种清单？
我一直在谷歌搜索，我找到的只是手册页，它并没有真正说明什么-p将修复或触发动手标志的原因。我对 ext4 文件系统特别感兴趣。
我的 Ubuntu 13.10 系统在过去一天左右的时间里表现非常糟糕。查看内核日志，似乎小于 1 年的 3TB SATA 磁盘的特定扇区存在问题：
Nov 4 20:54:04 mediaserver kernel: [10893.039180] ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Nov 4 20:54:04 mediaserver kernel: [10893.039187] ata4.01: BMDMA stat 0x65
Nov 4 20:54:04 mediaserver kernel: [10893.039193] ata4.01: failed command: READ DMA EXT
Nov 4 20:54:04 mediaserver kernel: [10893.039202] ata4.01: cmd 25/00:08:f8:3f:83/00:00:af:00:00/f0 tag 0 dma 4096 in
Nov 4 20:54:04 mediaserver kernel: [10893.039202] res 51/40:00:f8:3f:83/40:00:af:00:00/10 Emask 0x9 (media error)
Nov 4 20:54:04 mediaserver kernel: [10893.039207] ata4.01: …我正在使用具有 debian 6 和 3 分区（FAT 和 2x ext2）的无风扇 PC（实际上有数百台）。该系统没有电源按钮，因此大多数人倾向于猛拉插头以“关闭它”而不是 init 0（或等效的）。结果，文件系统很快就会产生错误。
我试过使用 'shutdown -rF' 来强制 fsck 但这似乎不起作用。我想知道是否有某种方法可以告诉系统在挂载之前检查每个挂载点/ FS。
我试过在 /etc/fstab 中设置 fsck 参数。这通常会给我一个“发现错误”。手动运行 fsck '消息。
还有其他选择可以尝试吗？
昨天，我们的一台计算机掉线了，grub或者说老实说，当我们打开机器时，我不确定它是什么外壳。
它表明由于不一致，它无法挂载根文件系统或某种意义上的东西。
我跑了，我相信：
fsck -fy /dev/sda2
重新启动，问题消失了。
问题部分来了：
我已经在她的 root 的 crontab 中：
Run Code Online (Sandbox Code Playgroud)@reboot /home/ruzena/Development/bash/fs-check.sh
而脚本包含：
#!/bin/bash
touch /forcefsck
想一想，我不知道，为什么我为这么短的命令创建了脚本文件，但无论如何......
此外，在文件中：
/etc/default/rcS
我已经定义：
Run Code Online (Sandbox Code Playgroud)FSCKFIX=yes
所以我不明白。怎么会出现这种情况？
我应该怎么做才能在启动时强制进行根文件系统检查（以及可选的修复）？
或者这两件事是我能做的最大的事情吗？
操作系统： Linux Mint 18.x Cinnamon 64 位。
fstab：
cat /etc/fstab | grep ext4
显示：
Run Code Online (Sandbox Code Playgroud)UUID=a121371e-eb12-43a0-a5ae-11af58ad09f4 / ext4 errors=remount-ro 0 1
grub：
Run Code Online (Sandbox Code Playgroud)fsck.mode=force
已经添加到grub配置中。
在启动时，我的笔记本电脑说：
fsck died with status code 4
手册页告诉我：
fsck 返回的退出代码是以下条件的总和：
[..]
4 - 文件系统错误未得到纠正
当我尝试以 root 身份修复错误时，fsck 说我的磁盘是干净的：
$ fsck /dev/sda1
/dev/sda1, clean [and some things about available blocks]
如何修复我的磁盘？