本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

了解同步的運作方式

S3 檔案可讓檔案系統和連結的 S3 儲存貯體自動同步。您主動使用的資料會複製到檔案系統，因此您可以使用標準 Linux 檔案操作，以低延遲讀取和寫入檔案。S3 檔案需要在連結的 S3 儲存貯體上啟用 S3 版本控制。當您在檔案系統上編輯檔案時，S3 檔案會將您的變更複製回 S3 儲存貯體，做為對應物件的新版本，確保保留舊版本。當其他應用程式新增、修改或刪除 S3 儲存貯體中的物件時，S3 檔案會自動反映檔案系統中的變更。當因為同時變更檔案系統和 S3 儲存貯體中的相同資料而發生衝突時，S3 檔案會在發生衝突時將 S3 儲存貯體視為事實來源。

為了最佳化儲存成本，S3 檔案會從檔案系統中移除您最近未使用的資料。您的資料會長期存放在連結的 S3 儲存貯體中，並在您下次存取時擷取回檔案系統。

S3 儲存貯體可透過檔案系統存取

建立 S3 檔案系統之後，您可以在運算資源上掛載 S3 儲存貯體，並立即開始存取 S3 儲存貯體資料。根據預設，當您第一次透過列出目錄的內容或在其中開啟檔案來存取目錄時，S3 檔案會從 S3 儲存貯體匯入該目錄中所有檔案的中繼資料，以及小於匯入大小閾值 （預設 128 KB) S3的檔案資料。目錄的第一次存取可能會有較高的延遲，但後續的讀取和寫入速度明顯更快。透過預先匯入中繼資料，S3 檔案可讓您瀏覽目錄內容、檢視檔案大小，以及檢查低延遲的許可。

例如，假設 S3 儲存貯體包含具有 1，000 個物件data/images/的字首。第一次執行 時ls /mnt/s3files/data/images/，S3 檔案會匯入所有 1，000 個檔案的中繼資料，並以非同步方式將低於匯入大小閾值的檔案資料複製到檔案系統。此初始清單可能需要幾秒鐘的時間，但該目錄中個別檔案cat的後續命令如 stat、 ls -la或 會以低延遲傳回。

對於大於匯入大小閾值的檔案，S3 檔案只會匯入中繼資料，而資料不會複製到檔案系統，而是在您存取時直接從 S3 儲存貯體讀取。您可以調整此閾值，以更符合工作負載。例如，對於重複存取相同檔案並受益於低延遲讀取的工作負載，您可以提高匯入量，以預先匯入更多資料。對於循序串流資料的工作負載，較低的閾值可能更具成本效益，因為當資料以大型區塊而非小型隨機讀取循序讀取時，預先匯入資料的延遲效益較不具意義。如需詳細資訊，請參閱自訂 S3 檔案的同步。

檔案系統中的變更會自動反映在 S3 儲存貯體中

當您在檔案系統中建立、修改或刪除檔案時，S3 檔案會自動將這些變更複製到 S3 儲存貯體。新檔案會變成新的 S3 物件，現有檔案的變更會變成新的物件版本，而刪除的檔案會變成 S3 刪除標記。

您透過檔案系統在檔案和目錄上設定的 POSIX 許可，例如擁有者 (UID)、群組 (GID) 和許可位元，會在對應的 S3 物件上儲存為使用者定義的 S3 物件中繼資料。當您使用 chmod、 chown或 變更許可時chgrp，S3 檔案會將這些變更連同任何資料變更一起匯出到您的 S3 儲存貯體。當 S3 檔案從您的 S3 儲存貯體匯入物件時，它會讀取此中繼資料，並在檔案系統上套用對應的 POSIX 許可。沒有 POSIX 許可中繼資料的物件會獲指派預設許可。

當您修改檔案系統中的檔案時，S3 檔案會等待最多 60 秒，在該時間彙總檔案的任何後續變更，然後再複製到 S3 儲存貯體。這表示在單一 S3 PUT 請求中擷取對相同檔案的快速連續寫入，而不是為每個個別變更產生新的物件版本，從而降低 S3 請求成本和儲存成本。如果您在 S3 檔案將變更複製回 S3 儲存貯體後繼續修改檔案，它會視需要複製後續變更。

例如，如果應用程式開啟日誌檔案並在 30 秒內附加 50 次，S3 檔案會將全部 50 個批次附加到單一 S3 PUT 請求。如果應用程式在第一次同步後繼續寫入，S3 檔案會在後續同步中複製其他變更。

S3 儲存貯體的變更會自動出現在您的檔案系統中

S3 檔案會使用 S3 事件通知來監控 S3 儲存貯體中的變更。當另一個使用 S3 API 的應用程式新增、修改或刪除 S3 儲存貯體中的物件時，S3 檔案會自動針對目前存放在檔案系統高效能儲存中的檔案，反映檔案系統中的這些變更。資料已從檔案系統過期的檔案不會更新，直到您下次存取它們為止，此時 S3 檔案會從 S3 儲存貯體擷取最新版本。

了解重新命名和移動操作的影響

Amazon S3 使用平面儲存結構，透過其金鑰名稱來識別物件。雖然 S3 檔案可讓您在目錄中組織資料，但 S3 沒有目錄的原生概念。在您的檔案系統中顯示為目錄的項目，是 S3 儲存貯體中物件金鑰共用的常見字首。此外，S3 物件不可變，且不支援原子重新命名。因此，當您重新命名或移動檔案時，S3 檔案必須使用更新後的金鑰將資料寫入新的物件，並刪除原始物件。當您重新命名或移動目錄時，S3 檔案必須針對共用該字首的每個物件重複此程序。因此，當您重新命名或移動包含數千萬個檔案的目錄時，S3 請求成本和同步時間會大幅增加。

當您嘗試建立範圍超過 1.25 億個物件的字首的檔案系統時，S3 檔案會傳回錯誤。此錯誤會提醒您，大型遞迴重新命名或移動操作可能會影響檔案系統效能，因為每個檔案都需要對 S3 儲存貯體提出個別的寫入和刪除請求。如果您仍然想要建立範圍限定於該字首的檔案系統，您可以新增 --AcceptBucketWarning 參數。

由於 S3 檔案會在 S3 儲存貯體上個別重新命名物件，因此在重新命名完成之前，兩個目錄都會顯示在 S3 儲存貯體上。在重新命名目錄之後，但在重新命名完全同步之前寫入的物件將不會移動。為了簡化資料重組工作，建議您不要在重新命名相符目錄時，透過 S3 儲存貯體建立新物件。

例如，如果您執行 mv /mnt/s3files/projects/alpha /mnt/s3files/projects/beta，重新命名會立即在檔案系統上完成。在 S3 儲存貯體上，S3 檔案會開始將每個物件複製和刪除至 S3 儲存貯體中的新金鑰 （以 取代projects/alpha/字首projects/beta/)，並刪除原始物件。在此過程中，S3 儲存貯體會暫時在 projects/alpha/和 下包含物件projects/beta/。移動所有物件後，只會projects/beta/保留 。

未使用的資料已從檔案系統過期，以最佳化儲存

S3 檔案會透過自動移除最近未從檔案系統讀取的檔案資料，來最佳化儲存成本。您的資料會安全地存放在 S3 儲存貯體中。S3 檔案只會從檔案系統移除複本。名稱、大小和許可等檔案中繼資料絕不會從檔案系統中移除，因此您可以低延遲繼續瀏覽檔案系統。

如果檔案系統中的檔案未讀取 30 天 （可設定），且其變更已同步至 S3 儲存貯體，S3 檔案會從檔案系統移除檔案資料。下次讀取該檔案時，S3 檔案會從 S3 儲存貯體擷取對應物件的最新版本，並將其複製回檔案系統。

例如，假設您在 1 月/mnt/s3files/data/batch-jan.parquet在 中處理資料集，而且不會再次存取該資料集。30 天後，S3 檔案會從檔案系統移除檔案資料。檔案仍會出現在具有正確大小和許可的目錄中，但資料不再位於檔案系統上。當您在 4 月再次讀取檔案時，S3 檔案會從 S3 儲存貯體擷取檔案，並將其複製回檔案系統。第一個讀取的延遲可能較高，但後續讀取速度很快。

S3 儲存貯體是發生衝突時的事實來源

當透過檔案系統修改相同的檔案，且對應的 S3 物件也在 S3 檔案將檔案系統變更同步回 S3 儲存貯體之前變更時，就會發生衝突。例如，您可以在另一個應用程式上傳對應物件的新版本時，透過掛載的檔案系統編輯檔案，或直接在連結的 S3 儲存貯體中刪除檔案。

S3 檔案在嘗試將檔案系統變更同步回 S3 儲存貯體時，或收到 S3 事件通知指出物件已變更時，偵測到衝突。您的 S3 儲存貯體做為資料的長期存放區，因此當發生衝突時，S3 檔案會將 S3 儲存貯體視為事實來源。這可提供可預測的一致性，確保 S3 儲存貯體中的版本一律優先。發生衝突時，S3 檔案會將衝突的檔案從檔案系統中的目前位置移至遺失和找到的目錄，並將最新版本從連結的 S3 儲存貯體匯入檔案系統。

例如，假設您/mnt/s3files/report.csv透過檔案系統編輯 。在 S3 檔案將您的變更同步回 S3 儲存貯體之前，另一個應用程式會將新版本的 report.csv直接上傳至 S3 儲存貯體。當 S3 檔案偵測到衝突時，會將您的 版本移至失物招領目錄report.csv，並將其取代為 S3 儲存貯體中的 版本。

失物招領目錄位於檔案系統的根目錄中，名稱為 .s3files-lost+found-file-system-id。當 S3 檔案將檔案移至遺失並找到的目錄時，它會在檔案名稱前面加上識別符，以區分可能隨時間移動的相同檔案的多個版本。失物招領目錄中的檔案不會複製到 S3 儲存貯體。您可以刪除檔案並從此目錄中複製檔案，但無法移動或重新命名其中的檔案或刪除目錄本身。如果您想要在 S3 儲存貯體中保留檔案系統變更，而非最新版本，請將檔案從失物清單複製回其原始路徑。您可以從失物招領目錄中檔案的延伸屬性擷取檔案的原始路徑。然後S3 檔案會將它複製到 S3 儲存貯體，做為物件的新版本。如需詳細資訊，請參閱對 S3 檔案進行故障診斷。

預設同步設定適用於大多數工作負載，以低延遲、以檔案為基礎的 S3 資料存取。如需如何設定這些參數的詳細資訊，請參閱 自訂 S3 檔案的同步。