我们有一个用于 GIS 数据库的系统（以 Postgres 为底层引擎），该系统使用 4x2TB Samsung EVO870 SATA SSD 软件 RAID 5 阵列作为其数据库驱动器。有一个夜间备份脚本，它将表转储到本地临时目录，对其进行 GZip 压缩，然后将其传输到单独的计算机（使用mv）。通常备份从 1830 开始，一直持续到 0500；是的，这是一个很大的备份。大约一个月前，外部系统脱机，因此该mv步骤停止工作，临时存储区充满了未移动的文件。外部系统修复后，我们注意到临时区域已满，并删除了其中的所有内容 - 大约 3.5TB 的文件。大约两周前，我们注意到每日备份直到 1000 点才完成。我怀疑事情已经变慢了，因为临时目录虽然已被删除，但并未被清除，所以当我们必须将新的临时文件作为备份的一部分写入时，我们必须先清理 SSD 块，然后才能重写它们。
fstrim -av没有打印任何内容，这表明没有文件系统表示它们支持 DISCARD。
此系统在 RAID 阵列顶部有 LVM。数据库和临时目录位于 ext4 文件系统中（以前是 ext2，但发生了一些事情），位于其自己的 LV 中，该 LV 安装在/db；fstrim -v /db报告File system does not support DISCARD。
操作系统版本：Debian Linux 8（jessie）、Linux 3.16.0-4-amd64 x86_64
RAID 信息：
root@local-database:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sda1[7] sdd1[4] sdc1[5] sdb1[6]
5860147200 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
bitmap: 1/2 pages [4KB], 524288KB chunk
root@local-database:~# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Sun Dec 27 17:55:35 2015
Raid Level : raid5
Array Size : 5860147200 (5588.67 GiB 6000.79 GB)
Used Dev Size : 1953382400 (1862.89 GiB 2000.26 GB)
Raid Devices : 4
Total Devices : 4
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Tue Aug 8 14:07:27 2023
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : local-database:0 (local to host local-database)
UUID : 18d38d9a:daaa0652:8e43a020:133e5a4f
Events : 53431
Number Major Minor RaidDevice State
7 8 1 0 active sync /dev/sda1
6 8 17 1 active sync /dev/sdb1
5 8 33 2 active sync /dev/sdc1
4 8 49 3 active sync /dev/sdd1
有关数据库和临时区域使用的特定 LV 的信息：
--- Logical volume ---
LV Path /dev/MainDisk/postgres
LV Name postgres
VG Name MainDisk
LV UUID TpKgGe-oHKS-Y341-029v-jkir-lJn8-jo8xmZ
LV Write Access read/write
LV Creation host, time local-database, 2015-12-27 18:04:04 -0800
LV Status available
# open 1
LV Size 4.78 TiB
Current LE 1251942
Segments 4
Allocation inherit
Read ahead sectors auto
- currently set to 6144
Block device 253:2
光伏信息：
root@local-database:~# pvdisplay
--- Physical volume ---
PV Name /dev/md0
VG Name MainDisk
PV Size 5.46 TiB / not usable 2.50 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 1430699
Free PE 121538
Allocated PE 1309161
PV UUID N3tcTa-LBw2-D8gI-6Jg4-9v3T-KWn2-5CDVzK
我真的很想将备份时间缩短到 11 小时，这样我们就不会再与实际工作时间发生冲突。TRIM 选项中有什么我可以做的吗，或者我是否遗漏了其他内容？我已检查数据库没有突然增加任何新表，也没有在一夜之间增长 50%；没有网络连接问题，据我所知，在我们开始花费 16 小时进行备份之前，网络或外部服务器没有发生任何异常。我还遗漏了什么吗？
编辑由于评论：实际的 SSD 只有一年半的历史，于 2022 年 4 月取代了原来的 250GB SSD。（空间不足，RAID 阵列、LV 和文件系统已就地扩展。）我们正在使用软件 RAID、骨标准 Linux mdadm。
编辑回应评论：
root@local-database:~# lsblk -d
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 1.8T 0 disk
sdb 8:16 0 1.8T 0 disk
sdc 8:32 0 1.8T 0 disk
sdd 8:48 0 1.8T 0 disk
root@local-database:~# cat /sys/module/raid456/parameters/devices_handle_discard_safely
N
root@local-database:~# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: AuthenticAMD
CPU family: 21
Model: 2
Model name: AMD FX(tm)-8320 Eight-Core Processor
Stepping: 0
CPU MHz: 1400.000
CPU max MHz: 3500.0000
CPU min MHz: 1400.0000
BogoMIPS: 7023.19
Virtualization: AMD-V
L1d cache: 16K
L1i cache: 64K
L2 cache: 2048K
L3 cache: 8192K
NUMA node0 CPU(s): 0-7
根据 Nikita Kyprianov 在下面评论中链接的一篇文章，三星 EVO 870s 与 AMD 硬件存在严重问题，这显然是事实。所以看起来就是这样。我想我们只能忍受它了……
答案1
您需要在 /etc/lvm.conf 中启用丢弃支持（issue_discards=1）
我不记得这是否需要在 md 中设置，但我的本地手册页中没有提及。