了解同步的工作原理

S3 Files 会自动使您的文件系统和关联的 S3 存储桶保持同步。您活跃使用的数据会复制到文件系统，因此，您可以使用标准 Linux 文件操作以较低的延迟读取和写入文件。S3 Files 要求在关联的 S3 存储桶上启用 S3 版本控制。当您在文件系统上编辑文件时，S3 Files 将您的更改作为相应对象的新版本复制回 S3 存储桶，并确保保留旧版本。当其它应用程序在您的 S3 存储桶中添加、修改或删除对象时，S3 Files 会自动在您的文件系统中反映这些更改。当由于对文件系统和 S3 存储桶中的相同数据进行并行更改而发生冲突时，S3 Files 将 S3 存储桶视为冲突情况下的事实来源。

为了优化存储成本，S3 Files 会从文件系统中删除您最近未使用的数据。您的数据将持久存储在关联的 S3 存储桶中，并在您下次访问它时将其提取回文件系统。

可通过文件系统访问 S3 存储桶

创建 S3 文件系统后，您可以在计算资源上挂载 S3 存储桶，然后立即开始访问 S3 存储桶数据。默认情况下，当您首次通过列出目录内容或在其中打开文件来访问目录时，S3 Files 会从 S3 存储桶导入该目录中所有文件的元数据，以及小于导入大小阈值（默认 128 KiB）的文件的数据。首次访问目录的延迟可能较高，但后续读取和写入的速度要快得多。通过预先导入元数据，S3 Files 使您能够以低延迟浏览目录内容、查看文件大小和检查权限。

例如，假设 S3 存储桶包含一个带有 1000 个对象的前缀 data/images/。首次运行 ls /mnt/s3files/data/images/ 时，S3 Files 会导入所有 1000 个文件的元数据，并将低于导入大小阈值的文件的数据异步复制到文件系统中。此初始列表可能需要几秒钟，但随后对该目录中各个文件执行的命令（例如 ls -la、stat 或 cat）会以低延迟返回。

对于大于导入大小阈值的文件，S3 Files 仅导入元数据，但不会将数据复制到文件系统，而是在您访问 S3 存储桶时直接从其中进行读取。您可以调整此阈值以更好地匹配您的工作负载。例如，对于重复访问相同文件并受益于低延迟读取的工作负载，您可以提高此阈值，以便预先导入更多数据。对于按顺序流式传输数据的工作负载，较低的阈值可能更具成本效益，因为当按顺序大块读取数据而不是小规模、随机读取数据时，提前导入数据的延迟优势意义不大。有关更多信息，请参阅 自定义 S3 Files 的同步。

文件系统中的更改自动反映在 S3 存储桶中

当您在文件系统中创建、修改或删除文件时，S3 Files 自动将这些更改复制至您的 S3 存储桶。新文件会变为新的 S3 对象，对现有文件的更改变为新的对象版本，而删除的文件成为 S3 删除标记。

您通过文件系统对文件和目录设置的 POSIX 权限，例如所有者（UID）、组（GID）和权限位，将作为用户定义的 S3 对象元数据存储在相应的 S3 对象上。当您使用 chmod、chown 或 chgrp 更改权限时，S3 Files 会将这些更改连同任何数据更改一起导出到您的 S3 存储桶。当 S3 Files 从 S3 存储桶导入对象时，它会读取此元数据，并在文件系统上应用相应的 POSIX 权限。将向没有 POSIX 权限元数据的对象分配默认权限。

当您在文件系统中修改文件时，S3 Files 最多会等待 60 秒，汇总这段时间内对文件的所有后续更改，然后再复制到 S3 存储桶。这意味着可以在单个 S3 PUT 请求中捕获对同一文件的快速连续写入，而不是为每个单独的更改生成新的对象版本，从而降低您的 S3 请求成本和存储成本。如果您在 S3 Files 将您的更改复制回 S3 存储桶后继续修改该文件，它将根据需要复制后续更改。

例如，如果应用程序打开一个日志文件并在 30 秒内向其追加 50 次内容，则 S3 Files 会将所有 50 次追加内容批处理到单个 S3 PUT 请求中。如果应用程序在第一次同步后继续写入，S3 Files 会在后续同步中复制其它更改。

S3 存储桶中的更改自动出现在文件系统中

S3 Files 使用 S3 事件通知来监控 S3 存储桶中的更改。当另一个使用 S3 API 的应用程序添加、修改或删除 S3 存储桶中的对象时，对于其数据当前存储在文件系统的高性能存储中的文件，S3 Files 会自动在文件系统中反映这些更改。文件系统中其数据已到期的文件要等到您下次访问它们时才会更新，此时 S3 Files 会从 S3 存储桶中检索最新版本。

了解重命名和移动操作的影响

Amazon S3 使用扁平存储结构，其中对象由其键名称标识。虽然 S3 Files 可让您在目录中组织数据，但 S3 没有原生的目录概念。文件系统中显示为目录的内容是由 S3 存储桶中对象的键共享的常用前缀。此外，S3 对象是不可变的，不支持原子重命名。因此，当您重命名或移动文件时，S3 Files 必须使用更新的键将数据写入新对象，然后删除原始键。重命名或移动目录时，S3 Files 必须对共享该前缀的每个对象重复此过程。因此，当您重命名或移动包含数千万个文件的目录时，您的 S3 请求成本和同步时间会显著增加。

当您尝试创建文件系统（范围限定为包含大量对象的前缀）时，S3 Files 会返回错误，因此重命名可能需要长达 4 个小时（大约多达 1200 万个对象）。此错误提醒您，大型递归重命名或移动操作可能会影响文件系统性能，因为每个文件都需要对您的 S3 存储桶发出单独的写入和删除请求。如果您仍想创建范围限定为该前缀的文件系统，则可以添加 --AcceptBucketWarning 参数。

由于 S3 Files 会单独重命名 S3 存储桶上的对象，因此在完全完成重命名之前，这两个目录都将在 S3 存储桶上可见。将不会移动在重命名目录之后但在重命名完全同步之前写入的对象。为了简化数据重组工作，我们建议您在重命名匹配的目录时，不要通过 S3 存储桶创建新对象。

例如，如果您运行 mv /mnt/s3files/projects/alpha /mnt/s3files/projects/beta，则文件系统上的重命名会立即完成。在 S3 存储桶上，S3 Files 开始将每个对象复制到其在 S3 存储桶中的新键并删除相应的对象（将 projects/alpha/ 前缀替换为 projects/beta/），然后删除原始对象。在此过程中，S3 存储桶暂时包含 projects/alpha/ 和 projects/beta/ 下的对象。所有对象都已移动后，仅 projects/beta/ 保持原样。

文件系统中未使用的数据会到期，以优化存储

S3 Files 通过自动从文件系统中移除近期未读取的文件数据来优化存储成本。您的数据仍安全地存储在 S3 存储桶中。S3 Files 仅从文件系统中移除副本。从不会从文件系统中移除文件元数据（例如名称、大小和权限），因此您可以继续以低延迟浏览文件系统。

如果文件系统中的某个文件已有 30 天（可配置）未被读取，并且其更改已同步到 S3 存储桶，则 S3 Files 会将文件数据从文件系统中移除。下次您读取该文件时，S3 Files 会从 S3 存储桶中检索相应对象的最新版本，并将其复制回文件系统。

例如，假设您在一月份处理了 /mnt/s3files/data/batch-jan.parquet 中的一个数据集，但不再访问该数据集。30 天后，S3 Files 会从文件系统中移除文件数据。该文件仍以其正确的大小和权限出现在目录列表中，但数据已不再位于文件系统上。当您四月份再次读取该文件时，S3 Files 从 S3 存储桶中检索该文件并将其复制回文件系统。第一次读取的延迟可能较高，但后续读取速度很快。

S3 存储桶是冲突时的事实来源

如果通过文件系统修改了同一个文件，并且在 S3 Files 将文件系统更改同步回 S3 存储桶之前，相应的 S3 对象也发生了更改，则会发生冲突。例如，您可能通过挂载的文件系统编辑文件，而另一个应用程序则直接在关联的 S3 存储桶中上传相应对象的新版本或将其删除。

当 S3 Files 尝试将文件系统更改同步回 S3 存储桶时，或者当它收到表明对象已更改的 S3 事件通知时，它会检测到冲突。S3 存储桶可作为数据的长期存储，因此 S3 Files 在发生冲突时将 S3 存储桶视为事实来源。这提供了可预测的一致性，确保您的 S3 存储桶中的版本始终优先。如果发生冲突，S3 Files 会将冲突的文件从其在文件系统中的当前位置移至丢失找回目录，并将最新版本从关联的 S3 存储桶导入到文件系统。

例如，假设您通过文件系统编辑 /mnt/s3files/report.csv。在 S3 Files 将您的更改同步回 S3 存储桶之前，另一个应用程序会将新版本的 report.csv 直接上传到 S3 存储桶。当 S3 Files 检测到冲突时，它将您的 report.csv 版本移至丢失找回目录，并将其替换为 S3 存储桶中的版本。

丢失找回目录位于文件系统的根目录中，名称为 .s3files-lost+found-file-system-id。如果您通过指定根目录的接入点挂载文件系统，则在该挂载中看不到丢失找回目录，因为它位于接入点的根目录的上方。要访问丢失找回目录，请在没有接入点的情况下挂载文件系统，或者使用没有根目录限制的接入点，这样您就可以通过接入点访问整个文件系统的范围。

当 S3 Files 将文件移到丢失找回目录时，它会在文件名前面加上标识符，以区分同一文件的多个版本，这些版本可能会随着时间推移而变动。丢失找回目录中的文件不会复制到您的 S3 存储桶中。您可以从该目录中删除文件和复制文件，但不能移动或重命名其中的文件，也不能删除该目录本身。如果您想在 S3 存储桶中保留文件系统更改而不是最新版本，请将文件从丢失找回目录复制回其原始路径。您可以从丢失找回目录中文件的扩展属性中检索文件的原始路径。然后，S3 Files 会将其作为对象的新版本复制到您的 S3 存储桶。有关更多信息，请参阅 S3 Files 故障排除。

默认同步设置将适用于大多数工作负载，以实现对 S3 数据的低延迟、基于文件的访问。有关如何配置这些参数的更多详细信息，请参阅自定义 S3 Files 的同步。