我曾经认为文件更改直接保存到磁盘中，也就是说，一旦我关闭文件并决定单击/选择“保存”。但是，在最近的一次对话中，我的一个朋友告诉我，通常情况并非如此。操作系统（特别是我们在讨论Linux系统的操作系统）将更改保存在内存中，并且它具有一个守护程序，该守护程序实际上将内存中的内容写入磁盘。
他甚至给出了外部闪存驱动器的示例：这些驱动器已安装到系统中（已复制到内存中），并且有时由于后台驻留程序尚未将内容保存到闪存中而导致数据丢失。这就是为什么我们卸载闪存驱动器。
我不了解操作系统的功能，因此我完全不知道这是否正确以及在哪种情况下。我的主要问题是：是否会像Linux / Unix系统（可能还有其他OS）中所述发生这种情况？例如，这是否意味着如果我在编辑和保存文件后立即关闭计算机，则更改很可能会丢失吗？也许这取决于磁盘类型-传统硬盘还是固态硬盘？
该问题专门针对具有磁盘来存储信息的文件系统，即使人们进行了任何澄清或比较也是如此。
如果在编辑并保存文件后立即关闭计算机，则更改很可能会丢失吗？
他们可能是。我不会说“最有可能”，但是可能性取决于很多事情。
一种提高文件写入性能的简单方法是，操作系统仅缓存数据，告知（说谎）应用程序写入经过的内容，然后稍后再进行实际写入。如果同时有其他磁盘活动在进行，这将特别有用：操作系统可以确定读取的优先级，并在以后进行写入。它还可以完全消除实际写入的需要，例如，在此之后快速删除临时文件的情况下。
如果存储速度较慢，则缓存问题会更加明显。将文件从快速的SSD复制到速度较慢的USB记忆棒可能会涉及很多写缓存，因为USB记忆棒无法跟上。但是您的cp命令返回得更快，因此您可以继续工作，甚至可以编辑刚刚复制的文件。
当然，这样的缓存有一个缺点，您可能会丢失一些数据，然后再将其实际保存。如果用户的编辑器告诉他们写入成功，但文件实际上不在磁盘上，那么用户会感到无所适从。这就是为什么要进行fsync()系统调用的原因，该调用仅在文件实际到达磁盘后才返回。在向用户报告写入成功之前，您的编辑器可以使用它来确保数据是正确的。
我说“应该”，因为驱动器本身可能会向OS发出相同的谎言，并说写入已完成，而文件实际上仅存在于驱动器中的易失性写缓存中。根据驱动器的不同，可能无法解决。
除之外fsync()，还有sync()和syncfs()系统调用，它们要求系统确保所有系统范围的写入或特定文件系统上的所有写入均已命中磁盘。该实用程序sync可用于调用这些程序。
然后还有O_DIRECTtoopen()的标志，该标志应“试图最大程度地减少往返于此文件的I / O的缓存影响”。删除缓存会降低性能，因此，它们通常由自己进行缓存并希望对其进行控制的应用程序（数据库）使用。（O_DIRECT并非没有问题，手册页中对此的评论有些有趣。）
断电时发生的情况还取决于文件系统。您不仅应该关注文件数据，还应该关注文件系统元数据。如果找不到，将文件数据存储在磁盘上并没有多大用处。仅将文件扩展到更大的大小就需要分配新的数据块，并且需要在某个位置标记它们。
文件系统如何处理元数据更改以及元数据和数据写入之间的顺序差异很大。例如，使用ext4，如果您设置了mount标志data=journal，则所有写入-甚至数据写入-都将通过日志，并且应该相当安全。这也意味着它们被写入两次，因此性能下降。默认选项会尝试对写入进行排序，以便在更新元数据之前将数据保存在磁盘上。其他选项或其他文件系统可能会更好或更坏；我什至不会尝试全面学习。
实际上，在负载较轻的系统上，文件应在几秒钟内命中磁盘。如果要处理可移动存储，请在拉动介质之前先卸载文件系统，以确保数据已实际发送到驱动器，并且没有进一步的活动。（或者让您的GUI环境为您执行此操作。）
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句