我想将系统设置为将大部分 RAM 用于文件系统元数据缓存，但对于读/写缓存和预取文件只使用相当少的 RAM。理想情况下，我希望能够浏览文件系统（尽可能多地放入 RAM），而无需启动磁盘，直到我真正打开文件。

以下是详细信息：

我有一个自制的文件服务器。它在大约 9TB 的 LVM 卷中有五个磁盘，但只有 4GB 的 RAM。由于服务器除了提供文件之外并没有做太多其他事情，因此大部分 RAM 用于缓存。（“免费”报告用于缓​​存的 3.9G 中有 3.4G。）

服务器住在我的卧室里，如果所有的磁盘都在旋转，它会在安静的时候发出足够的噪音。（我的意思不是搜索噪音，只是旋转噪音。磁盘有各种品牌和型号，我认为旋转速度的细微差异会引起干扰。没有磁盘本身会产生噪音，但如果其中一些一起旋转，则会有亚赫兹周期的轻微噪音。）所以我将服务器配置为大部分时间都降低磁盘转速。

当然，如果在我的文件管理器中打开文件夹时磁盘转速下降，那么无论哪个磁盘具有该文件夹转速都会有延迟。只是这没什么大不了的。但是，根据我查看的位置，如果 LVM 碰巧将每个子文件夹的元数据分布在不同磁盘上，它可能会连续发生多次。

我怀疑 Linux 主要用文件内容填充其缓存，可能还有预取数据。超过几 MB 的缓存对于确保流畅播放不是很有用；如果我只是看了一部电影，我可能很快就不会再看它了。预取，如果发生的话，在我的情况下也是完全没用的，在超过几 MB 之后。

但是有人会认为 4GB 应该足以缓存大多数文件系统元数据，至少那些已经访问过的部分，这样我就可以浏览文件而无需启动磁盘，如果事实证明它们是睡眠。

打开文件时仍然会有延迟，但没关系。比较“点击；等待; 点击; 等待; 点击; 等待; 玩; 用“点击”观看”；点击; 点击; 玩; 等待; 手表”。前者令人难以置信地令人沮丧；后者几乎在意料之中。

笔记：

1. 没关系，内核是3.2，操作系统是Debian，卷是lvm2，FS是ext4。

2. 减速的唯一原因是夜间噪音；否则服务器会持续运行。（我把它做得尽可能低功耗。）降速延迟取决于一天中的时间。

3. 硬盘仅用于媒体。操作系统位于单独的（小）闪存驱动器上。（这意味着任何启动延迟都来自数据，而不仅仅是因为它需要一些东西/usr或其他东西。如果它能以某种方式帮助我解决问题，我可以在上面节省几 GB。

4. 对性能的合理影响没什么大不了的。无论如何，磁盘比我的网络快。

我如何描述或解释输出中的“缓冲区” free？

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           501M        146M         19M        9.7M        335M        331M
Swap:          1.0G         85M        938M

$ free -w -h
              total        used        free      shared     buffers       cache   available
Mem:           501M        146M         19M        9.7M        155M        180M        331M
Swap:          1.0G         85M        938M

我对这个系统没有任何（已知的）问题。我只是惊讶和好奇地看到“缓冲区”几乎和“缓存”一样高（155M vs 180M）。我认为“缓存”代表文件内容的页面缓存，并且往往是“缓存/缓冲区”中最重要的部分。我不确定什么是“缓冲区”。

例如，我将其与具有更多 RAM 的笔记本电脑进行了比较。在我的笔记本电脑上，“缓冲区”数字比“缓存”小一个数量级（200M 与 4G）。如果我了解什么是“缓冲区”，那么我就可以开始研究为什么缓冲区在较小的系统上增长到如此大的比例。

来自man proc（我忽略了“大”这个滑稽过时的定义）：

缓冲区 %lu

原始磁盘块的相对临时存储，不应变得非常大（20MB 左右）。

缓存 %lu

从磁盘读取的文件的内存缓存（页面缓存）。不包括 SwapCached。

$ free -V
free from procps-ng 3.3.12

$ uname -r  # the Linux kernel …

我试图找出有关缓存的细节（特别是哪些缓存在内核之间共享，哪些不是）并且发现了不一致。

sudo lshw 说

*-cache:0
     description: L1 cache
     physical id: a
     slot: Internal Cache
     size: 64KiB
     capacity: 64KiB
     capabilities: synchronous internal write-back
*-cache:1
     description: L2 cache
     physical id: b
     slot: External Cache
     size: 8MiB
     capabilities: synchronous internal write-back

但lscpu声称

L1d cache:   32K
L1i cache:   32K
L2 cache:   256K
L3 cache:  8192K

我不太担心指令和数据缓存加在一起，但是L2去哪儿了？

在运行 Ubuntu 10.10 的机器上观察，或者uname -a说：

Linux name 2.6.35-32-generic #66-Ubuntu SMP Mon Feb 13 21:04:32 UTC 2012 x86_64 GNU/Linux

这是一个普遍的问题，但请注意，我能找到的最精确的制造商规范和维基百科都没有必要的细节。

无关的奖励问题：是否 …

手册页说明barrier了 ext4的选项：

写屏障强制对日志提交进行适当的磁盘排序，使易失性磁盘写入缓存可以安全使用，但会降低一些性能。如果您的磁盘以一种或另一种方式由电池供电，则禁用屏障可以安全地提高性能。

带电池（和 SSD）的笔记本电脑是否算作有电池供电的磁盘？那么，barrier=0ext4 在笔记本电脑上安全吗？

这是内存图在运行 CentOS 的 VPS 上的样子，该 VPS 具有 512MB 的 RAM 和 nginx/php-fpm/mysqld，每天为数千名访问者提供（主要是静态的）内容。

（这些是 x 轴上的天数）

正如您所看到的，它在缓存和缓冲区中非常不稳定。内存缓存会以不定期的时间间隔清除（排除负责的 cron 作业）。它通常（但并非总是）在它不能变大的时候被清除。有时它几乎完全清除，有时只清除一半。

我试图理解这些清除背后的逻辑。我希望文件数据的缓存时间更长，并且在清除内存缓存时不会看到任何其他程序使用比平时更多的内存。

这是正常行为，还是我错过了什么？

更新：内存升级似乎已经稳定了图表。仍然看到小幅下降，但没有升级之前那么显着。

我知道当页面缓存页面被修改时，它被标记为脏并需要写回，但在以下情况下会发生什么：

场景： 文件/apps/EXE是一个可执行文件，被完全分页到页面缓存中（它的所有页面都在缓存/内存中）并被进程P执行

持续发布然后用全新的可执行文件替换 /apps/EXE。

假设 1： 我假设进程 P（以及具有引用旧可执行文件的文件描述符的任何其他人）将继续使用旧的内存 /apps/EXE 没有问题，并且任何尝试执行该路径的新进程都将获得新的可执行文件。

假设 2： 我假设如果不是文件的所有页面都映射到内存中，那么事情会很好，直到出现页面错误需要已替换​​文件中的页面，并且可能会发生段错误？

问题 1： 如果您使用 vmtouch 之类的东西 mlock 文件的所有页面，这是否会改变场景？

问题 2： 如果 /apps/EXE 位于远程 NFS 上，那会有什么不同吗？（我认为不是）

请更正或验证我的 2 个假设并回答我的 2 个问题。

让我们假设这是一个带有某种 3.10.0-957.el7 内核的 CentOS 7.6 机器

更新：进一步思考，我想知道这个场景是否与任何其他脏页场景没有什么不同..

我想写入新二进制文件的进程将读取并获取所有缓存页面，因为它都被分页了，然后所有这些页面都将被标记为脏。如果它们被锁定，在引用计数变为零后，它们将只是占据核心内存的无用页面。

我怀疑当当前正在执行的程序结束时，其他任何东西都会使用新的二进制文件。假设这一切都是正确的，我想只有当只有部分文件被分页时才有趣。

通常，当我运行 Duplicity 时，我会在运行结束时看到这样的错误消息：

Cleanup of temporary file /home/user/.cache/duplicity/9a169830d41477b2dbc3c5b32edd4e8a/duplicity-MEXhMY-tempdir/mktemp-StAkzj-1 failed

提到的目录将包含十个左右的文件，下次运行 Duplicity 时将删除这些文件。

知道为什么在运行增量备份时有时会失败吗？我自己没有看到任何模式，也很难找到其他人提到同样的问题。某个电子邮件列表上的某个人曾经提到他的语言环境给 Duplicity 造成了问题。我尝试从我的正常挪威 bokmål 语言环境更改为 en-US，但仍然看到问题。

这只是 Duplicity 的正常操作吗？

在三个不同的系统上看到它：两个 Ubuntu 13.04 64 位桌面和一个 Ubuntu Server 13.04 64 位。

我有百万4-20 KB文件的目录（可以产生类似的这样的文件：seq 10000 | gzip > a; seq 1000000 | parallel --bar 'head -c{=$_=int(rand()*16)+4=}k a > {}'）

. 我需要复制那个目录。但似乎我必须为每个文件做一个搜索，所以这需要很长时间。

有什么方法可以加快速度吗？

我目前在想，如果我能得到这些文件占用的磁盘块，我可以对它们进行排序，合并接近的块（鉴于顺序读取通常比寻找更快）并读取这些块，以便它们在 RAM 中在进行复制之前缓存（我有 32 GB RAM）。

但是为了让它工作，我需要一种方法来识别文件所在的块。

我在磁性设备（即不是 SSD）上使用 EXT4。

编辑：

这应该有效，但它没有：

ls |
parallel -IOO --pipe "sudo parallel -j100 hdparm --fibmap {}'|tail -n +5'" |
sort -nk 2 | 
perl -ane 'if($u+10000 < $F[1]) { print "$l ",($u-$l),"\n"; $l=$F[1] } $u=$F[2]' |
sudo parallel --colsep ' ' dd if=/dev/sda1 skip={1} bs=512 count={2} '| cat >/dev/null'

在大文件上测试时，它不会缓存文件。

编辑2： …

如何使用 KDE 在 Debian 9.1 中刷新 DNS 缓存？

抽象的

有时，Linux 内核不知道外部 USB 存储设备的驱动器写入缓存。在这种情况下是否有必要在分离这些设备之前显式刷新这些缓存？

例子

我使用 WD Elements 外置 USB 硬盘，上面hdparm -I写着

...
Commands/features:
    Enabled Supported:
       ...
       *    Write cache
...

和hdparm -W：

...
 write-caching =  1 (on)

另一方面，当我插入驱动器时，我收到以下内核消息：

... No Caching mode page found
... Assuming drive cache: write through

根据Kyle Jones 的这个回答，这些内核消息表明内核假设它的写操作将直接进入盘片。

Linux 内核文档中的文件Documentation/block/queue-sysfs.txt 的“write_cache (RW)”部分描述了内核假设通过缓存写入模式的含义（感谢Wayne Conrad）：

...“直写”，...还将消除内核发出的缓存刷新。

问题

到目前为止，我从 Linux 系统分离外部 USB 存储设备的标准方法是卸载它上所有已安装的分区，等到驱动器的 LED 停止闪烁，物理拔下 USB 连接器，如果这不会关闭电源设备（有些具有单独的电源），以明确关闭电源。

这种方法是否安全，或者它是否意味着在驱动器写入缓存中丢失未刷新数据的风险，特别是如果内核不知道该缓存？

在后一种情况下，似乎建议在卸载后通过发送 SCSI 同步命令显式刷新驱动器上的写入缓存。例如sg_sync，可以使用 sg3-utils 附带的 which来完成： …