小编lxg*_*xgr的帖子

前段时间，有一些关于 ext4 在不干净的卸载后可能留下空文件的讨论，这篇文章总结得很好。基本上，由于延迟分配，写入可以在写入缓存中保留比 ext 日志的默认提交间隔（5 秒）更长的时间。

这些问题似乎已在一个补丁中得到解决，该补丁在某些情况下强制分配块，从而默认情况下最多 5 秒后强制数据到磁盘。

我想知道当应用程序覆盖文件的现有部分而不截断或附加文件本身时会发生什么。是否也会在 5 秒内强制写入磁盘？

这似乎与追加到文件的情况不同：追加时，文件大小发生变化，这是元数据的变化；因此，需要在 5 秒内提交日志，并且由于 data=ordered，出于安全考虑，必须在此之前写入数据（否则其他用户的已删除文件的一部分可能会显示给附加文件的所有者）文件）。

当只是覆盖文件数据时，没有理由必须在元数据日志提交之前进行数据写入，因为旧数据与新数据属于同一用户。那么写入是否发生在提交之前，或者是否可以延迟比日志提交间隔更长的时间？如果有，多长时间？

更新：我知道所有这些在做正确的事情时都是无关紧要的，即使用 fsync()。（这是所有关于 ext4 和数据丢失的讨论的主要原因——问题只涉及应用程序而不是 fsync()ing，或者不是在正确的时刻。）我不是在写我自己的应用程序，我问是因为我不知道我的所有应用程序是否都做正确的事情，我想知道这种“危险”写入的大致时间范围。问的原因是我的显卡驱动经常导致kernel panic，我想知道我是否需要担心超过最后5秒的数据写入。

有许多关于 3D 编程（OpenGL 或 DirectX）和相应图形管道的资源可用，但我想知道它们在现代 GPU 上实现的级别。

到目前为止，我已经能够发现已经从实现图形管道各个阶段的非常专业的电路转向了更通用的方法。这种转换已部分反映在可编程着色器形式的 3D API 上。大多数晶体管似乎专用于执行实际着色器指令的大规模并行 SIMD 单元。

但是图形管道的其余部分呢？这仍然在硬件中实现吗？

现代 GPU（想想 Nvidia Fermi）基本上是一组“愚蠢的”SIMD 阵列，这些阵列从 CPU 和各种缓存中获取指令和数据，所有将图形管道映射到这些指令的实际逻辑都发生在图形驱动程序中?

或者在 GPU 的某处是否有一些控制单元将传入的高级指令和数据流（编译的着色器程序、顶点数据和属性以及纹理）转换为实际的 SIMD 指令并负责同步、内存分配等？

我怀疑现实介于这两个极端之间，答案会相当冗长，而且基于大量猜测（某些 GPU 供应商拒绝发布有关其产品的任何文档，更不用说驱动程序了，这肯定是有原因的）源代码...），但任何有关正确方向和有用资源的提示都将不胜感激。

到目前为止，我发现了一系列博客文章，这些文章对于更多地了解现代 GPU 非常有用，但是我缺少关于整体架构的某种更高层次的概述 - 我可以理解大部分提到的概念，但是不太明白它们是如何组合在一起的。

新的 Thunderbolt 3 连接标准使用 USB Type-C 插头和电缆。根据英特尔的介绍（如果我正确解释了幻灯片 13-15），所有 Thunderbolt 端口也支持 DisplayPort 替代模式，因此在每个 Thunderbolt 3 USB-C 插头上，都可以通过适配器连接 DisplayPort 显示器。

一些 USB-C 交替模式适配器仅使用部分线对作为替代用途，例如 Apple 的 AV 多端口适配器使用两根线对用于 DisplayPort，其余两根用于 5 Gbit/s 的 USB 3.1 传输（请参阅本幻灯片的第五张幻灯片）介绍）。

这些“混合备用模式”适配器是否也适用于 Thunderbolt 端口，或者 USB 和 DisplayPort 在英特尔的 Thunderbolt 实施（Alpine Ridge）上是否互斥？外部坞站上的 Thunderbolt 端口怎么样？

如果这不是 DisplayPort-over-USB 或 Thunderbolt 3 规范中指定的内容，我也会很高兴有一些轶事证据表明在支持 Thunderbolt 的 USB 端口上工作的“混合替代模式”适配器。

“仅替代模式”适配器的一个示例是Google 的 USB-C 到 DisplayPort 电缆（它使用所有四个通道作为 DisplayPort 输出，因此绝对可以与 Thunderbolt 3 端口配合使用）；“混合替代模式”适配器的一个例子是Apple 的 AV Multiport 适配器。

我很清楚在使用 inode 的文件系统上删除打开的文件是如何工作的 - unlink() 只是将链接计数减少到零，并且当文件的最后一个文件句柄关闭时，inode 将被删除。

但是，在 Linux 中使用不使用 inode 的文件系统（如 FAT32）时，它是如何工作的？

一些实验表明删除打开的文件仍然是可能的（不像在 Windows 上，unlink 调用不会成功），但是当文件系统被不干净地卸载时会发生什么？

当文件系统本身不支持这样的操作时，Linux 如何将文件标记为未链接？是刚刚删除的目录项，还保留在内存中吗（无论如何都保证卸载后删除，但会使文件系统处于不一致的状态），还是只在内存中标记删除，并在删除时写入关闭最后一个文件句柄，避免可能的损坏，但在不干净的卸载后恢复已删除的文件？

在维基百科对 TCP 的描述中，指出

服务器端的会话数仅受内存限制，并且可以随着新连接的到来而增长，但客户端必须在向服务器发送第一个 SYN 之前分配一个随机端口。

第一部分似乎合乎逻辑：服务器仅使用客户端连接的端口作为源端口，因此仅受（客户端 IP 数）*（临时客户端端口数）的限制 - 一个很大的数字。

但是为什么客户不能做基本相同的事情呢？如果套接字 A 使用临时端口 12345 连接到服务器 1（例如客户端：12345 -> 服务器 1:80），为什么套接字 B 不能通过重用相同的源端口（客户端：12345 -> 服务器 2:80）连接到服务器 2？这将允许来自单个主机的多个（端口数量）传出 TCP 连接。

TCP 规范中是否有禁止这种端口重用的内容，或者限制只是常见 TCP 实现的实际结果？如果是这样，第一种情况是否真的以与第二种情况不同的方式处理，或者单个服务器端口上的传入 TCP 连接数实际上也限制为 65535？

为了澄清起见，我正在寻找以下方面的理论（根据规范）和实际（实施；尤其是 Linux）限制：

• 从单个客户端到任何服务器/端口的传出连接。 (client:* -> *:*)
• 从单个客户端到相同服务器和端口的连接(client:* -> server:port)- 这显然不能大于 65535。
• 从任何客户端到单个服务器端口的传入连接(*:* -> server:port)- 根据引用的段落和上述原因，我怀疑这大于 65535。