对于上下文：我需要能够可靠地更新某些 sqlite DB 文件上的时间戳，这些文件会在 ext4 文件系统上获得间歇性更新。
写入数据库时使用touch命令（更新最后修改时间）会失败，甚至更糟，导致数据丢失吗？
我怎样才能知道我是否格式化了驱动器
mkfs.ext4 -m 0 -T largefile4
或不指定选项 -m 和 -T
mkfs.ext4
换句话说，我怎样才能看到格式化驱动器的 -m reserved-blocks-percentage 和 -T usage-type 是什么？
文件系统位于 LVM RAID5 上。它似乎工作正常：
$ sudo pvs
[sudo] password for jrwren:
PV VG Fmt Attr PSize PFree
/dev/sda2 datavg lvm2 a-- <7.28t 2.80t
/dev/sdb2 datavg lvm2 a-- <3.64t 0
/dev/sdc2 datavg lvm2 a-- <7.28t <7.28t
/dev/sdd2 datavg lvm2 a-- <7.28t 0
/dev/sde2 datavg lvm2 a-- <7.28t 73.82g
/dev/sdf1 datavg lvm2 a-- <3.64t 0
/dev/sdg2 datavg lvm2 a-- <7.28t 3.99t
/dev/sdh2 datavg lvm2 a-- <447.11g 8.00m
/dev/sdi2 datavg lvm2 a-- <9.10t 2.21t
$ sudo lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
lxd2 datavg -wi-ao---- 147.10g
mirrored datavg -wi-ao---- 300.00g
m datavg Rwi-aor--- 3.52t 100.00
m3 datavg Rwi-aor--- 4.00t 100.00
mu datavg Rwi-aor--- 1.00t 100.00
nomirror datavg -wi-ao---- 2.20t
photos datavg Rwi-aor--- 200.00g 100.00
stor datavg Rwi-aor--- 300.00g 100.00
storj datavg -wi-ao---- 1.00t
t datavg Rwi-aor--- 6.00t 100.00
t2 datavg Rwi-aor--- 3.90t 100.00
我有一个进程对名为 m 的逻辑卷进行多次读取。这是设备 dm-12。最终，它会随着以下内核消息而死。
Jun 30 16:02:33 delays kernel: [393661.035286] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: com[68/1946]t main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Jun 30 16:02:33 delays kernel: [393661.039726] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Jun 30 16:02:33 delays kernel: [393661.044175] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Jun 30 16:02:33 delays kernel: [393661.048584] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Jun 30 16:02:33 delays kernel: [393661.054717] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Jun 30 16:02:33 delays kernel: [393661.060977] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Jun 30 16:02:33 delays kernel: [393661.063736] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Jun 30 16:02:33 delays kernel: [393661.066283] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Jun 30 16:02:33 delays kernel: [393661.068773] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Jun 30 16:02:33 delays kernel: [393661.071232] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365192: comm rtorrent main: pblk 765519712 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
我卸载文件系统并运行 e2fsck：
$ sudo e2fsck -p /dev/datavg/m
movies contains a file system with errors, check forced.
movies: Inode 118751237 has an invalid extent node (blk 475078659, lblk 0)
movies: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
$ sudo e2fsck -y /dev/datavg/movies
e2fsck 1.45.7 (28-Jan-2021)
movies contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 177471496 has an invalid extent node (blk 709943175, lblk 0)
Clear? yes
...
Pass 1E: Optimizing extent trees
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -(709943175--709943176) -(868210688--868212735) -(868214784--868216831) -(868253696--868255743) -(868257792--868259839) -(868886528--868888575) -(868892672--868894719) -(868896768--868898815) -(868900864--868902911) -(868904960--868907007) -(868909056--868911103) -(868913152--868917247) -(868921344--868923391) -(868925440--868927487) -(868929536--868931583) -(868933632--868935679) -(868937728--868939775) -(868941824--868943871) -(868945920--868947967) -(868950016--868954111) -(868958208--868960013) -(869894144--869922573)
Fix? yes
Free blocks count wrong for group #21665 (24561, counted=24563).
Fix? yes
Free blocks count wrong for group #26495 (28672, counted=32768).
Fix? yes
Free blocks count wrong for group #26497 (18432, counted=22528).
Fix? yes
Free blocks count wrong for group #26516 (22528, counted=32768).
Fix? yes
Free blocks count wrong for group #26517 (16384, counted=32768).
Fix? yes
Free blocks count wrong for group #26518 (16626, counted=26624).
Fix? yes
Free blocks count wrong for group #26547 (2290, counted=30720).
Fix? yes
Free blocks count wrong (366951912, counted=367025158).
Fix? yes
movies: ***** FILE SYSTEM WAS MODIFIED *****
movies: 6896/236224512 files (20.8% non-contiguous), 577868794/944893952 blocks
$ sudo e2fsck -p /dev/datavg/movies
movies: clean, 6896/236224512 files, 577868794/944893952 blocks
它说它很干净，所以我重新安装它并重新运行阅读软件。
几分钟后：
Jun 30 16:34:49 delays kernel: [395595.309814] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365190: comm rtorrent main: pblk 765517692 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Jun 30 16:34:49 delays kernel: [395595.317838] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365190: comm rtorrent main: pblk 765517692 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Jun 30 16:34:49 delays kernel: [395595.320836] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365190: comm rtorrent main: pblk 765517692 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Jun 30 16:34:49 delays kernel: [395595.323418] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365190: comm rtorrent main: pblk 765517692 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Jun 30 16:35:14 delays kernel: [395619.785771] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365190: comm rtorrent main: pblk 765517692 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Jun 30 16:35:14 delays kernel: [395619.793135] EXT4-fs error (device dm-12): ext4_find_extent:885: inode #191365190: comm rtorrent main: pblk 765517692 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
这里发生了什么？LVM 是否腐败并在欺骗我？有没有我可以运行检查的命令？我应该运行一个坏块（e2fsck -c）还是什么？
内核没有相应的 LVM 消息。如果底层磁盘有问题，我预计会出现 LVM 错误。到底是怎么回事？
更新：有人要求 dmesg 输出。这正是上面 EXT4-fs 消息的内容。dmesg 输出中除了标准引导消息之外的唯一其他消息是重复的：
[527724.593062] rptaddrs[3948921]: segfault at 7ffc7a7a50b5 ip 00007fd9f0f86820 sp 00007ffc7a7a3fc8 error 4 in libc-2.28.so[7fd9f0e4c000+148000] [527724.593075] Code: 7f 07 c5 fe 7f 4f 20 c5 fe 7f 54 17 e0 c5 fe 7f 5c 17 c0 c5 f8 77 c3 48 39 f7 0f 87 ab 00 00 00 0f 84 e5 fe ff ff c5 fe 6f 26 <c5> fe 6f 6c 16 e0 c5 fe 6f 74 16 c0 c5 fe 6f 7c 16 a0 c5 7e 6f 44
我正在考虑加快谷歌云虚拟机上一些繁重的数据库写入工作量。我看到 ext4 FS 的 nobarrier 选项可以提供一些性能提升。我想知道是否有人知道将 nobarrier 选项与谷歌持久存储（Balanced PD）一起使用是否安全。我的理解是If your disks are battery-backed in one way or another, disabling barriers may safely improve performance，但我不知道这如何适用于谷歌平衡 PD 存储。与不使用 nobarrier 选项相比，如果我的 VM 挂起或在发生写操作时执行 VM 硬重置，我会遇到更多 FS 损坏/问题吗？
配置错误的 logrotate 在我的服务器上的一个目录中产生了很多文件。ls | wc -l显示 5,387,172 个文件，据此du -sh总计约 8 GB。dmesg显示了许多这样的错误：
[16718682.749947] EXT4-fs warning (device dm-5): ext4_dx_add_entry:2209: Directory (ino: 4194315) index full, reach max htree level :2
[16718682.750028] EXT4-fs warning (device dm-5): ext4_dx_add_entry:2213: Large directory feature is not enabled on this filesystem
配置现在已修复，我删除了所有不应该存在的文件。清理后，我得到了这个：
# ls -l roundcube/logs/
total 20
-rw-r--r-- 1 www-data www-data 0 Mär 21 06:25 errors.log
-rw-r--r-- 1 www-data www-data 315 Mär 21 06:25 errors.log.1
-rw-r--r-- 1 www-data www-data 0 Jan 7 06:36 errors.log.10.gz
-rw-r--r-- 1 www-data www-data 0 Dez 18 06:26 errors.log.11.gz
-rw-r--r-- 1 www-data www-data 0 Dez 10 06:25 errors.log.12.gz
-rw-r--r-- 1 www-data www-data 321 Mär 14 06:25 errors.log.2.gz
-rw-r--r-- 1 www-data www-data 272 Mär 7 06:25 errors.log.3.gz
-rw-r--r-- 1 www-data www-data 354 Feb 28 06:25 errors.log.4.gz
-rw-r--r-- 1 www-data www-data 20 Feb 18 16:07 errors.log.5.gz
-rw-r--r-- 1 www-data www-data 0 Feb 18 18:14 errors.log.6.gz
-rw-r--r-- 1 www-data www-data 0 Feb 5 13:36 errors.log.7.gz
-rw-r--r-- 1 www-data www-data 0 Jan 29 09:17 errors.log.8.gz
-rw-r--r-- 1 www-data www-data 0 Jan 14 06:49 errors.log.9.gz
# du -sh roundcube/logs/
632M roundcube/logs/
然而，ls通话仍然需要很长时间（我没有看时钟，但我认为它超过了 10 分钟）。也可能 > 60 分钟。而且很奇怪，du仍然报告 632MB。
我启动了一个救援系统并运行 fsck：
root@rescue /dev/mapper # fsck.ext4 vg0-mail
e2fsck 1.44.5 (15-Dec-2018)
vg0-mail: clean, 300078/13107200 files, 13579986/52428800 blocks
root@rescue /dev/mapper # fsck.ext4 -f vg0-mail
e2fsck 1.44.5 (15-Dec-2018)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
vg0-mail: 300078/13107200 files (0.5% non-contiguous), 13579986/52428800 blocks
所以看起来一切都很好。我重新启动回到正常系统，但ls仍然很慢。
只是为了确保没有进程干扰，我重新启动到救援系统，在那里安装卷并尝试列出目录内容。它也挂了。
strace ls显示很多行。最后几行是：
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
read(3, "nodev\tsysfs\nnodev\ttmpfs\nnodev\tbd"..., 1024) = 309
read(3, "", 1024) = 0
close(3) = 0
access("/etc/selinux/config", F_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=5547600, ...}) = 0
mmap(NULL, 5547600, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f0bd79c6000
close(3) = 0
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCGWINSZ, {ws_row=66, ws_col=271, ws_xpixel=0, ws_ypixel=0}) = 0
stat("roundcube/logs/", {st_mode=S_IFDIR|0755, st_size=662331392, ...}) = 0
openat(AT_FDCWD, "roundcube/logs/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=662331392, ...}) = 0
getdents64(3
所以它似乎挂了getdents64？我有点困惑，它以看似不完整的线条结尾。
我读到这可能是由硬件缺陷引起的，所以我尝试smartctl -t long在两个磁盘上运行分析（raid 1）。结果如下：
/dev/sda
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.19.0-14-amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Seagate Constellation ES.3
Device Model: ST2000NM0033-9ZM175
Serial Number: Z1X0QWWG
LU WWN Device Id: 5 000c50 064a202c3
Firmware Version: SN07
User Capacity: 2.000.398.934.016 bytes [2,00 TB]
Sector Size: 512 bytes logical/physical
Rotation Rate: 7200 rpm
Form Factor: 3.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2 (minor revision not indicated)
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Tue Mar 23 21:24:30 2021 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x82) Offline data collection activity
was completed without error.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 592) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 245) minutes.
Conveyance self-test routine
recommended polling time: ( 2) minutes.
SCT capabilities: (0x50bd) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 070 063 044 Pre-fail Always - 11974882
3 Spin_Up_Time 0x0003 096 096 000 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 25
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 088 060 030 Pre-fail Always - 706711710
9 Power_On_Hours 0x0032 033 033 000 Old_age Always - 59193
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 24
184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0
189 High_Fly_Writes 0x003a 059 059 000 Old_age Always - 41
190 Airflow_Temperature_Cel 0x0022 060 050 045 Old_age Always - 40 (Min/Max 36/44)
191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 18
193 Load_Cycle_Count 0x0032 099 099 000 Old_age Always - 2459
194 Temperature_Celsius 0x0022 040 050 000 Old_age Always - 40 (0 21 0 0 0)
195 Hardware_ECC_Recovered 0x001a 042 015 000 Old_age Always - 11974882
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 59192 -
# 2 Short offline Interrupted (host reset) 10% 59185 -
# 3 Extended offline Completed without error 00% 53208 -
# 4 Extended offline Completed without error 00% 53191 -
# 5 Extended offline Completed without error 00% 53178 -
# 6 Short offline Completed without error 00% 53170 -
# 7 Extended offline Completed without error 00% 53056 -
# 8 Extended offline Completed without error 00% 53040 -
# 9 Extended offline Completed without error 00% 53025 -
#10 Short offline Completed without error 00% 53017 -
#11 Extended offline Completed without error 00% 51660 -
#12 Extended offline Completed without error 00% 51643 -
#13 Extended offline Completed without error 00% 2411 -
#14 Extended offline Completed without error 00% 2383 -
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
/dev/sdb
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.19.0-14-amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Hitachi/HGST Ultrastar 7K4000
Device Model: HGST HUS724020ALA640
Serial Number: PN2138P2GNK30J
LU WWN Device Id: 5 000cca 24bc9579a
Firmware Version: MF6OAA70
User Capacity: 2.000.398.934.016 bytes [2,00 TB]
Sector Size: 512 bytes logical/physical
Rotation Rate: 7200 rpm
Form Factor: 3.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS T13/1699-D revision 4
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Tue Mar 23 22:38:27 2021 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x84) Offline data collection activity
was suspended by an interrupting command from host.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 24) seconds.
Offline data collection
capabilities: (0x5b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 314) minutes.
SCT capabilities: (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000b 100 100 016 Pre-fail Always - 0
2 Throughput_Performance 0x0005 136 136 054 Pre-fail Offline - 80
3 Spin_Up_Time 0x0007 163 163 024 Pre-fail Always - 367 (Average 396)
4 Start_Stop_Count 0x0012 100 100 000 Old_age Always - 28
5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0
7 Seek_Error_Rate 0x000b 100 100 067 Pre-fail Always - 0
8 Seek_Time_Performance 0x0005 145 145 020 Pre-fail Offline - 24
9 Power_On_Hours 0x0012 095 095 000 Old_age Always - 37639
10 Spin_Retry_Count 0x0013 100 100 060 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 27
192 Power-Off_Retract_Count 0x0032 099 099 000 Old_age Always - 1311
193 Load_Cycle_Count 0x0012 099 099 000 Old_age Always - 1311
194 Temperature_Celsius 0x0002 150 150 000 Old_age Always - 40 (Min/Max 22/60)
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0
197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 0
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 37638 -
# 2 Short offline Interrupted (host reset) 90% 37630 -
# 3 Extended offline Completed without error 00% 31654 -
# 4 Extended offline Completed without error 00% 31637 -
# 5 Extended offline Completed without error 00% 30951 -
# 6 Extended offline Completed without error 00% 30932 -
# 7 Extended offline Completed without error 00% 30927 -
# 8 Short offline Completed without error 00% 30919 -
# 9 Extended offline Completed without error 00% 30882 -
#10 Extended offline Completed without error 00% 30866 -
#11 Extended offline Completed without error 00% 19849 -
#12 Extended offline Completed without error 00% 19832 -
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
我大部分都不懂，但对我来说看起来并不“坏”？！
最终我刚刚执行mv logs logs-old; mv logs-old/* logs; rm -r logs-old了这似乎确实“解决了”我现在的问题。但我想知道这是否真的是这样，或者是否可能还有更多。
这里可能发生了什么导致这种目录列表极慢的行为？现在问题可以解决了吗？我应该找到一些损坏吗？
ext4 元数据校验和的内核 wiki 页面标记为“最后修改于 2013 年 10 月 22 日”。我找不到有关此功能的更多最新状态信息，除了 2019 年的这个问题，它建议禁用它和相关64bit功能。那里的答案之一声称该64bit功能“未经充分测试”，但我不确定这是否正确。这种说法没有任何根据，而且鉴于近年来 64 位系统的流行，这听起来值得怀疑。我知道metadata_csum取决于64bit完整的校验和。
我的问题：
截至 2020+，这两个相关的功能（metadata_csum和64bit）是否被认为是稳定和安全的？真的，它们经过了怎样的测试？在启用这些之前，是否应该考虑任何重要的错误、陷阱或故障模式？
我已经安装了数千个 Wordpress 共享主机，并且多年来我一直希望有一种以明智和安全的方式删除所有重复文件的好方法。我正在寻找更好的磁盘缓存命中率和更简单的备份。
我只是使用标准的 Ext4，而不是像 ZFS 这样内置的东西（需要付费）。
我熟悉像 rdfind 这样的工具几乎是完美的。它可以扫描所有文件，找到重复项并将它们硬链接在一起。我可以在非高峰时间每周运行一次，从而使成本几乎为零。
问题是我想要一个帐户更改文件以破坏硬链接并再次提供它自己的文件副本。这样一个站点更新 Wordpress 或插件就不会与任何其他站点混淆。这也将消除潜在的安全问题，因为没有帐户能够篡改另一个帐户的文件。链接的写时复制排序。
这样的事情可能吗？我试过做一些搜索，但我找不到任何东西。
当我在脚本中运行 /sbin/mkfs.ext4 -O ^64bit /dev/app/mysqldata 命令时，它给了我以下错误：
nd(): null: With return code "1", Output from: "/sbin/mkfs.ext4 -O ^64bit /dev/app/mysqldata"
mke2fs 1.42.9 (20-Jan-2014)
mkfs.ext4: Size of device (0x1b48caa00 blocks) /dev/app/mysqldata too big to be expressed
in 32 bits using a blocksize of 4096.
但如果我在没有 -O ^64bit 的情况下运行，它运行良好。有人可以帮忙吗？
/sbin/mkfs.ext4 /dev/app/mysqldata
raid10 中有一个卷，/dev/md3
它在 ext4 中有一个 GPT 分区/dev/md3p1，大小为 16TB。
我不小心跑了
fsck -y /dev/md3
导致文件系统/dev/md3p1损坏。
fsck -b superblock_number /dev/md3p1任何超级块 frommkfs -n /dev/md3p1都会返回错误。
testdisk in/dev/md3看到 ext4 分区，但 in/dev/md3p1什么也没看到。
如何恢复数据或分区？
sudo parted -l /dev/md3
Model: ATA WDC WD8003FFBX-6 (scsi)
Disk /dev/sda: 8002G
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 538MB 537MB fat32 boot, esp
2 538MB 1612MB 1074MB
3 1612MB 55.3GB 53.7GB
4 55.3GB 66.0GB 10.7GB
5 66.0GB 8002GB 7936GB
Model: ATA WDC WD8003FFBX-6 (scsi)
Disk /dev/sdb: 8002GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 538MB 537MB fat32 boot, esp
2 538MB 1612MB 1074MB
3 1612MB 55.3GB 53.7GB
4 55.3GB 66.0GB 10.7GB
5 66.0GB 8002GB 7936GB
Model: ATA WDC WD8003FFBX-6 (scsi)
Disk /dev/sdc: 8002GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 538MB 537MB fat32 boot, esp
2 538MB 1612MB 1074MB
3 1612MB 55.3GB 53.7GB
4 55.3GB 66.0GB 10.7GB
5 66.0GB 8002GB 7936GB
Model: ATA WDC WD8003FFBX-6 (scsi)
Disk /dev/sdd: 8002GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 538MB 537MB fat32 boot, esp
2 538MB 1612MB 1074MB
3 1612MB 55.3GB 53.7GB
4 55.3GB 66.0GB 10.7GB
5 66.0GB 8002GB 7936GB
sudo mount /dev/md3p1 /1
mount: /1: wrong fs type, bad option, bad superblock on /dev/md3p1, missing codepage or helper program, or other error.
sudo mkfs -n /dev/md3p1
mke2fs 1.44.1 (24-Mar-2018)
Creating filesystem with 3874701824 4k blocks and 484339712 inodes
Filesystem UUID: dc34be44-6f5a-47ac-a841-cbb75625b9b0
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776, 644972544, 1934917632,
2560000000, 3855122432
sudo fsck -b 32768 /dev/md3p1
fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
fsck.ext2: Bad magic number in super-block while trying to open /dev/md3p1
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>
cat /proc/mdstat
Personalities : [raid1] [raid10] [linear] [multipath] [raid0] [raid6] [raid5] [raid4]
md0 : active raid1 sdc2[6] sdb2[5] sda2[4] sdd2[0]
1046528 blocks super 1.2 [4/4] [UUUU]
md1 : active raid1 sdb3[6] sdc3[5] sdd3[0] sda3[4]
52395008 blocks super 1.2 [4/4] [UUUU]
md2 : active raid10 sdb4[5] sda4[4] sdc4[3] sdd4[0]
20953088 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
md3 : active raid10 sda5[1] sdd5[0] sdc5[3] sdb5[2]
15498811392 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
bitmap: 0/116 pages [0KB], 65536KB chunk
我们的 wordpress 网站已有数年历史，有许多帖子被索引并在 google 上排名很好。对于任何严重的流量，我的 wordpress 服务器都无法使用 - 即使在几轮 wordpress 优化之后也会发生这种情况。我们已经受够了 wordpress 问题，并决定迁移。
我们正在从 wordpress 迁移到静态站点以获得更好的性能，以便不会为每个请求呈现页面，并且静态 html、css、js 和图像文件可以直接由 nginx Web 服务器提供，而不是在后端访问另一台服务器。
问题是我们有超过 400,000 个帖子，每个帖子都有一个静态页面，因此我们将在其中存储相关文件，例如该帖子的 html 和图像文件。所以我们的主网络文件夹将有超过 400,000 个子文件夹。这会是Linux上的问题吗？或者这会成为我的 Web 服务器性能的问题吗？在这种情况下，托管方面有什么我应该关心的吗？
这里有没有人尝试过将 ext4 与 nginx 一起使用，并且文件夹中有大量子文件夹？真的会影响性能吗？有关于 ext4 处理大量文件夹的性能的相互矛盾的报告......我们不希望迁移增加复杂性，除非确实有必要。迁移对我们来说已经是一项艰巨的任务 :) 并且我们希望使其尽可能简单，除非存在性能下降的真正风险。有没有人在单个文件夹中使用具有大量子文件夹或文件的 nginx 网络服务器？
先感谢您。