# 了解同步的工作原理
S3 Files 会自动使您的文件系统和关联的 S3 存储桶保持同步。您活跃使用的数据会复制到文件系统，因此，您可以使用标准 Linux 文件操作以较低的延迟读取和写入文件。S3 Files 要求在关联的 S3 存储桶上启用 S3 版本控制。当您在文件系统上编辑文件时，S3 Files 将您的更改作为相应对象的新版本复制回 S3 存储桶，并确保保留旧版本。当其它应用程序在您的 S3 存储桶中添加、修改或删除对象时，S3 Files 会自动在您的文件系统中反映这些更改。当由于对文件系统和 S3 存储桶中的相同数据进行并行更改而发生冲突时，S3 Files 将 [S3 存储桶视为冲突情况下的事实来源](#s3-files-sync-source-of-truth)。
为了优化存储成本，S3 Files 会从文件系统中删除您最近未使用的数据。您的数据将持久存储在关联的 S3 存储桶中，并在您下次访问它时将其提取回文件系统。
## 可通过文件系统访问 S3 存储桶
创建 S3 文件系统后，您可以[在计算资源上挂载 S3 存储桶](s3-files-attach-compute.md)，然后立即开始访问 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-files-synchronization-customizing.md)。
## 文件系统中的更改自动反映在 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 请求成本和存储成本。您可以将这个 60 秒的非活跃时段用作导出触发器。例如，如果应用程序每 30 秒向一个文件追加数据，总共为 5 分钟，则 S3 Files 会在第 6 分钟开始导出过程。如果您进行其它更改，则该过程会在每 60 秒钟的无写入活动期后重复。
## 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-files-troubleshooting.md)。
**注意**
S3 Files 移至丢失找回目录的冲突文件会无限期地保留在那里，并计入您的文件系统存储成本。当不再需要时，您应该从丢失找回目录中删除文件以释放存储空间。
默认同步设置将适用于大多数工作负载，以实现对 S3 数据的低延迟、基于文件的访问。有关如何配置这些参数的更多详细信息，请参阅[自定义 S3 Files 的同步](s3-files-synchronization-customizing.md)。
**Topics**
+ [可通过文件系统访问 S3 存储桶](#s3-files-sync-bucket-accessible)
+ [文件系统中的更改自动反映在 S3 存储桶中](#s3-files-sync-changes-to-bucket)
+ [S3 存储桶中的更改自动出现在文件系统中](#s3-files-sync-changes-from-bucket)
+ [了解重命名和移动操作的影响](#s3-files-sync-rename-move)
+ [文件系统中未使用的数据会到期，以优化存储](#s3-files-sync-expiration)
+ [S3 存储桶是冲突时的事实来源](#s3-files-sync-source-of-truth)
+ [自定义 S3 Files 的同步](s3-files-synchronization-customizing.md)