相关疑难解决方法(0)

我在各种 Linux 服务器上将 XFS 文件系统作为数据/增长分区运行了近 10 年。

我注意到最近运行 6.2+ 版本的 CentOS/RHEL 服务器有一个奇怪的现象。

从 EL6.0 和 EL6.1 迁移到较新的操作系统版本后，稳定的文件系统使用变得高度可变。最初安装 EL6.2+ 的系统表现出相同的行为；显示 XFS 分区上磁盘利用率的剧烈波动（请参见下图中的蓝线）。

之前和之后。从 6.1 升级到 6.2 发生在星期六。

同一系统上一季度的磁盘使用图，显示了上周的波动情况。

我开始检查文件系统中是否有大文件和失控进程（可能是日志文件？）。我发现我最大的文件报告的值与du和不同ls。du使用和不使用--apparent-size开关运行说明了差异。

# du -skh SOD0005.TXT
29G     SOD0005.TXT

# du -skh --apparent-size SOD0005.TXT
21G     SOD0005.TXT

在整个文件系统中使用ncdu 实用程序进行快速检查，结果如下：

Total disk usage: 436.8GiB  Apparent size: 365.2GiB  Items: 863258

文件系统充满了稀疏文件，与之前版本的操作系统/内核相比，损失了近 70GB 的空间！

我仔细阅读了Red Hat Bugzilla并更改了日志，以查看是否有任何关于 XFS 的相同行为或新公告的报告。

纳达。

我在升级过程中从内核版本 …

在多层（物理驱动器 -> md -> dm -> lvm）的情况下，调度程序、预读设置和其他磁盘设置如何交互？

假设您有多个磁盘 (/dev/sda - /dev/sdd)，它们都是使用 mdadm 创建的软件 RAID 设备 (/dev/md0) 的一部分。每个设备（包括物理磁盘和 /dev/md0）都有自己的 IO 调度程序设置（像这样更改）和预读（使用 blockdev 更改）。当你加入 dm（加密）和 LVM 之类的东西时，你会添加更多具有自己设置的层。

例如，如果物理设备有 128 个数据块的预读，而 RAID 有 64 个数据块的预读，当我从 /dev/md0 读取时，这是正确的吗？md 驱动程序是否尝试读取 64 个块，然后物理设备驱动程序将其转换为 128 个块的读取？或者 RAID 预读是否“直通”到底层设备，导致读取 64 个块？

同样的问题也适用于调度程序？我是否必须担心多层 IO 调度程序以及它们如何交互，或者 /dev/md0 是否有效地覆盖了底层调度程序？

在我试图回答这个问题时，我挖掘了一些关于调度程序和工具的有趣数据，这些数据可能有助于解决这个问题：

• 来自 Google 的 Linux 磁盘调度程序基准测试
• blktrace - 在块设备上生成 I/O 流量的跟踪
• 相关的 Linux 内核邮件列表线程

我们想使用 XFS 来格式化服务器中的一些分区。高性能当然是我们的目标，但我们更喜欢稳定性。例如，如果发生断电，我们希望快速恢复 FS。在这种情况下，如果分区损坏并且不能再使用，这是不可接受的。我们可以更改 mkfs.xfs 的选项以提高稳定性吗？

有些人建议这样做：

mkfs.xfs –b size=4096 –s size=4096 /dev/sdx -f

我的问题是：

1. 块 4096 字节是否对性能来说太小了？如果我改进它，是否会影响稳定性？

2. 扇区大小应该由低级块设备驱动程序考虑，为什么 XFS 也有“扇区大小”？如果系统是具有传统 512 字节扇区支持的 Linux，将其设置为 4096 字节有什么问题吗？