当我启动我的 Linux 并开始写入 USB 支持的块设备时，前几次一切正常。
之后，如果我再次写信，dd报告的传输速率非常高（2.9 GB/s，这是不可能的），而且看起来很成功。但是当我将它插入任何其他计算机时，我可以清楚地看到它保存着旧数据。然而，即使重新插入（选中xxd），我的 Linux 也会报告新数据！这应该意味着它将数据保存在缓存中，而不是刷新它。只有在重新启动时，它才最终再次起作用。
我尝试了许多不同的事情：运行、sync传递、、、conv=sync写入3 、很好地关闭 USB 、等待 30 秒、尝试用 写入零等，但它们最终都没有做任何事情。conv=fdatasyncoflag=direct/proc/sys/vm/drop_cachesudisksctlcat
我什至将我的 Linux 系统切换到其他系统（我几乎从不这样做），因为之前的系统无论如何都是一团糟，但是，不出所料，Linux 是一团糟。这是一个全新的 1 天旧 Debian 11。
有任何想法吗？
在我的新 Fedora 31 安装中，没有\dev\bcache0. 缓存设备是 Raid 1：
# ls -d /dev/b*
/dev/block /dev/bsg /dev/btrfs-control /dev/bus
# bcache-super-show /dev/md127
sb.magic ok
sb.first_sector 8 [match]
sb.csum CDCAF0DD6B68FD24 [match]
sb.version 1 [backing device]
dev.label (empty)
dev.uuid b17ceaac-27ec-44d8-8bbb-235cfaa0c4a4
dev.sectors_per_block 1
dev.sectors_per_bucket 1024
dev.data.first_sector 16
dev.data.cache_mode 1 [writeback]
dev.data.cache_state 1 [clean]
cset.uuid de075a7c-af4e-43e9-b229-804322e3d263
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 223.6G 0 disk
├─sda1 8:1 0 700M 0 part /boot
├─sda2 8:2 0 700M 0 part /boot/efi
├─sda3 8:3 0 26G 0 part
│ └─luks-9793c78f-723c-4218-865f-83dbc4659192 253:1 0 26G 0 crypt [SWAP]
└─sda4 8:4 0 162G 0 part
└─luks-569b1153-2fab-4984-b1b6-c4a02ee206ef 253:0 0 162G 0 crypt /
sdb 8:16 0 111.8G 0 disk
├─sdb1 8:17 0 40G 0 part
└─sdb2 8:18 0 71.8G 0 part
sdc 8:32 0 1.8T 0 disk
└─sdc1 8:33 0 1.8T 0 part
└─md127 9:127 0 1.8T 0 raid1
sdd 8:48 0 1.8T 0 disk
└─sdd1 8:49 0 1.8T 0 part
└─md127 9:127 0 1.8T 0 raid1
sde 8:64 1 58.9G 0 disk
├─sde1 8:65 1 20G 0 part
└─sde2 8:66 1 38.9G 0 part
sr0 11:0 1 1024M 0 rom
# blkid | grep -E "md127|sdb1"
/dev/sdb1: UUID="057a2f23-c7b1-4264-a534-183ef9cad53b" TYPE="bcache" PARTLABEL="Linux filesystem" PARTUUID="505789f1-0523-4c62-bdb1-81bc0cc7bff1"
/dev/md127: UUID="b17ceaac-27ec-44d8-8bbb-235cfaa0c4a4" TYPE="bcache"
以上输出是否意味着设备正常且未损坏？
在这个新安装之后，我让它像以前安装的 Fedora 30 一样工作。然后我调整了缓存设备分区 ( sdb1) 的大小，现在我无法使支持设备显示为 bcache 设备。
我无法注册它：
# echo /dev/md127 > /sys/fs/bcache/register
-bash: echo: write error: Invalid argument
# echo de075a7c-af4e-43e9-b229-804322e3d263 > /sys/fs/bcache/register
-bash: echo: write error: Invalid argument
既不附加
# echo de075a7c-af4e-43e9-b229-804322e3d263 > /sys/block/md127/bcache/attach
-bash: echo: write error: No such file or directory
该文件退出：
# ll /sys/block/md127/bcache/attach
--w-------. 1 root root 4096 Jan 5 10:37 /sys/block/md127/bcache/attach
我错过了什么？
我有一个 shell 脚本，它反复清除缓存
echo 3 > /proc/sys/vm/drop_caches
问题是这最终会完全淹没 dmesg，因为它运行得太频繁了。
有没有办法在抑制生成的内核消息的同时做到这一点？
我知道：
虚拟内存分为用户空间和内核空间，并映射到物理内存。当用户进程访问文件时，内核将在授予进程访问权限（页面缓存）之前将该文件缓存到内存中。
然而
页面缓存的内存空间会受到内核空间的限制吗？或者除了linux中的配置之外，还有哪些东西会限制页面缓存大小？
我有 8 gb 的 ram、ssd 并且对 ram Android studio/gradle 非常贪婪。有时当 gradle 构建项目（吃 ram）时，它会挂起所有 ubuntu（和 xubuntu）。ui 变得如此迟钝 - 鼠标光标每 10 秒移动 1 厘米。
我不知道为什么会发生这种情况，似乎没有人知道，因为在互联网上有几个问题，比如我在互联网上关于“工作室冻结 ubuntu”、“大量 ram 应用程序冻结 ubuntu”、“满 ram 时 ubuntu 挂起”等。症状是一样的。并且自 2007 年以来也有跟踪错误。这似乎是非常特殊的情况，因为在某一时刻 gradle 需要大量内存来操作磁盘上的大文件。似乎同时它需要内存和存储来处理大文件。并以某种方式挂起系统。
所以我的问题是- 是否有任何选项可以禁用 buff/cache？或者也许像swappines（0..100）这样的参数但是用于buff / cache？我知道我不应该关心用于缓存的 ram，因为它随时可用，但我认为在这种情况下它不能正常工作。也许我大错特错）
设备块大小通常为 512 字节，而文件系统块大小通常为 4096 字节。为什么它们不同？为什么 512B 和 4KB 是设备和文件系统块大小的好选择？什么块大小最适合在用户空间库中缓存磁盘读取？
有害的 USB 记忆棒失速问题- LWN.net，2013 年 11 月。
Artem S. Tashkinov 最近遇到了至少一些 LWN 读者会熟悉的问题。将慢速存储设备（比如 USB 记忆棒或媒体播放器）插入 Linux 机器并向其中写入大量数据。整个系统继续挂起，可能持续几分钟。
不过，这一次，Artem 做了一个有趣的观察：使用 64 位内核运行时系统会停顿，但在同一硬件上使用 32 位内核时没有遇到此类问题。
文章解释说，使用 64 位内核，脏页缓存（写回缓存）默认允许增长到内存的 20%。对于 32 位内核，它实际上被限制在 ~180MB。
Linus 建议在 64 位上也将其限制为 ~180MB，但是当前的 Linux (v4.18) 不这样做。将Linus 建议的 patch与Linux 4.18中的当前功能进行比较。反对这种变化的最大论据来自戴夫·钦纳。他指出，过多地减少缓冲会导致文件系统出现碎片。他还解释说，“对于流式 IO，我们通常需要至少 5 秒的缓存脏数据来平衡延迟。”
我很困惑。为什么 U 盘停顿会导致整个系统挂起？
我很困惑，因为我读过一篇描述2011 年合并的代码（Linux 3.2）的早期文章。它显示内核应该在每个设备的基础上控制脏页缓存：
无 I/O 脏节流- LWN.net，2011
这就是 Fengguang 的补丁集的用武之地。他正试图创建一个控制循环，能够确定在任何给定时间每个进程应该被允许脏多少页。超出其限制的进程只是简单地休眠一段时间，以允许写回系统赶上它们。
[...]
系统的目标是将脏页数保持在设定值；如果事情变得不正常，将施加越来越大的力量将事情恢复到应有的位置。
[...]
但是，如果不考虑支持设备 (BDI)，则无法真正计算出该比率。一个进程可能正在弄脏存储在给定 BDI 上的页面，并且系统目前可能有过多的脏页面，但限制该进程的智慧还取决于该 BDI 存在多少脏页面。[...] 具有少量脏页的 BDI 可以快速清除其积压，因此即使系统比人们可能想要的更脏，它也可能负担得起更多。因此，补丁集使用一个复杂的公式调整特定 BDI 的计算 pos_ratio，该公式查看该特定 BDI 与其自己的设定点及其观察到的带宽之间的距离。最终结果是一个修改后的 pos_ratio，它描述了系统应该对给定 BDI 支持的更多或更少页面以及多少页面进行污染。
甚至比这更早添加了每设备控制：Smarter write throttling , 2007 LWN.net。[PATCH 0/23] 每个设备脏节流 -v10。它被合并到Linux 版本 2.6.24中。
有害的 USB 记忆棒失速问题- LWN.net，2013。
将慢速存储设备（比如 USB 记忆棒或媒体播放器）插入 Linux 机器并向其中写入大量数据。整个系统继续挂起，可能持续几分钟。
这篇文章预测了对内核默认值的简单更改。在 64 位 x86 上，默认情况下允许回写缓存增长到系统 RAM 的 20%。Linus 建议在所有平台上有效地将其限制为 ~180MB，模仿 32 位 x86 代码的限制。但是，当前的 Linux (v4.18) 不包括建议的更改。（将Linus 的 patch与v4.18中的当前函数进行比较）。
2013 LWN 文章称该问题是“相当于缓冲膨胀问题的存储”。现在有一篇 2016 LWN 文章介绍了一个新的 Linux 特性，称为 writeback throttling ( wbt/ CONFIG_WBT/ wbt_lat_usec)。这篇文章将写回限制描述为一种缓解“反映网络堆栈中出现的问题的缓冲区膨胀问题”的方法。这听起来非常相似:-)。
现在是否解决了特定的 U 盘失速问题？
走向不那么烦人的背景写回- LWN.net，2016
这是我们很多人都有过的经历：将一堆数据写入一个相对较慢的块设备，然后尝试完成一些其他工作。在许多情况下，系统会缓慢爬行，甚至会出现一段时间的冻结；在大量数据写入设备之前，事情不会恢复。在具有大量内存和缓慢 I/O 设备的系统上，将事物恢复到可工作状态可能需要很长时间，有时以分钟为单位。Linux 用户对这种行为模式不以为然，这是可以理解的，但它已经顽固地存在了很长时间。现在，也许，一个新的补丁集会改善这种情况。
受此问题启发：System lags when doing large R/W operations on external disks
块设备提供缓冲。这意味着write()在内核将数据写入设备之前，块设备上可以返回成功。程序可以通过调用来等待所有缓冲的写入fsync()。
我已经使用dd（或cat）将文件系统映像写入设备。这些命令默认不调用fsync()。
接下来，假设我要将mount写入的块设备作为文件系统。
我认为sync在安装它之前使用该命令是最安全的。但是如果我不同步块设备怎么办？文件系统是否有可能尝试读取一些尚未写入设备的块？那么它可以读取设备的旧内容，而不是文件系统映像中的正确数据吗？
我的主要兴趣是 Linux 行为。（而且 StackExchange 鼓励我提出一个具体问题。不过，我也可以对任何替代或历史行为表示赞同 :-)。