Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Vorladen von Dateien in Ihr Dateisystem
<a name="preload-file-contents-hsm-dra"></a>

Sie können optional Inhalte einzelner Dateien oder Verzeichnisse vorab in Ihr Dateisystem laden.

## Dateien mithilfe von HSM-Befehlen importieren
<a name="preload-hsm"></a>

Amazon FSx kopiert Daten aus Ihrem Amazon S3 S3-Daten-Repository, wenn auf eine Datei zum ersten Mal zugegriffen wird. Aufgrund dieses Ansatzes kommt es beim ersten Lesen oder Schreiben in eine Datei zu einer geringen Latenz. Wenn Ihre Anwendung empfindlich auf diese Latenz reagiert und Sie wissen, auf welche Dateien oder Verzeichnisse Ihre Anwendung zugreifen muss, können Sie optional Inhalte einzelner Dateien oder Verzeichnisse vorab laden. Dazu verwenden Sie den `hsm_restore` folgenden Befehl.

Sie können den `hsm_action` Befehl (der mit dem `lfs` Benutzerprogramm ausgegeben wird) verwenden, um zu überprüfen, ob der Inhalt der Datei vollständig in das Dateisystem geladen wurde. Der Rückgabewert von `NOOP` gibt an, dass die Datei erfolgreich geladen wurde. Führen Sie die folgenden Befehle von einer Recheninstanz aus, auf der das Dateisystem eingehängt ist. {{path/to/file}}Ersetzen Sie es durch den Pfad der Datei, die Sie vorab in Ihr Dateisystem laden.

```
sudo lfs hsm_restore {{path/to/file}}
sudo lfs hsm_action {{path/to/file}}
```

Sie können Ihr gesamtes Dateisystem oder ein ganzes Verzeichnis innerhalb Ihres Dateisystems vorladen, indem Sie die folgenden Befehle verwenden. (Das nachstehende Und-Zeichen sorgt dafür, dass ein Befehl als Hintergrundprozess ausgeführt wird.) Wenn Sie das gleichzeitige Vorladen mehrerer Dateien anfordern, FSx lädt Amazon Ihre Dateien parallel aus Ihrem Amazon S3 S3-Daten-Repository. Wenn eine Datei bereits in das Dateisystem geladen wurde, wird sie durch den `hsm_restore` Befehl nicht erneut geladen.

```
nohup find {{local/directory}} -type f -print0 | xargs -0 -n 1 -P 8 sudo lfs hsm_restore &
```

**Anmerkung**  
Wenn Ihr verknüpfter S3-Bucket größer als Ihr Dateisystem ist, sollten Sie in der Lage sein, alle Dateimetadaten in Ihr Dateisystem zu importieren. Sie können jedoch nur so viele tatsächliche Dateidaten laden, wie in den verbleibenden Speicherplatz des Dateisystems passen. Sie erhalten eine Fehlermeldung, wenn Sie versuchen, auf Dateidaten zuzugreifen, obwohl im Dateisystem kein Speicherplatz mehr vorhanden ist. In diesem Fall können Sie die Speicherkapazität nach Bedarf erhöhen. Weitere Informationen finden Sie unter [Verwaltung der Speicherkapazität](managing-storage-capacity.md).

## Schritt zur Validierung
<a name="preload-validation"></a>

Sie können das unten aufgeführte Bash-Skript ausführen, um herauszufinden, wie viele Dateien oder Objekte sich in einem archivierten (veröffentlichten) Zustand befinden.

Um die Leistung des Skripts zu verbessern, insbesondere in Dateisystemen mit einer großen Anzahl von Dateien, werden CPU-Threads automatisch anhand der `/proc/cpuproc` Datei bestimmt. Das heißt, Sie werden eine schnellere Leistung mit einer Amazon EC2 EC2-Instance mit einer höheren vCPU-Anzahl erzielen.

1. Richten Sie das Bash-Skript ein.

   ```
   #!/bin/bash
   
   # Check if a directory argument is provided
   if [ $# -ne 1 ]; then
       echo "Usage: $0 /path/to/lustre/mount"
       exit 1
   fi
   
   # Set the root directory from the argument
   ROOT_DIR="$1"
   
   # Check if the provided directory exists
   if [ ! -d "$ROOT_DIR" ]; then
       echo "Error: Directory $ROOT_DIR does not exist."
       exit 1
   fi
   
   # Automatically detect number of CPUs and set threads
   if command -v nproc &> /dev/null; then
       THREADS=$(nproc)
   elif [ -f /proc/cpuinfo ]; then
       THREADS=$(grep -c ^processor /proc/cpuinfo)
   else
       echo "Unable to determine number of CPUs. Defaulting to 1 thread."
       THREADS=1
   fi
   
   # Output file
   OUTPUT_FILE="released_objects_$(date +%Y%m%d_%H%M%S).txt"
   
   echo "Searching in $ROOT_DIR for all released objects using $THREADS threads"
   echo "This may take a while depending on the size of the filesystem..."
   
   # Find all released files in the specified lustre directory using parallel
   # If you  get false positives for file names/paths that include the word 'released',
   # you can grep 'released exists archived' instead of just 'released'
   time sudo lfs find "$ROOT_DIR" -type f | \
   parallel --will-cite -j "$THREADS" -n 1000 "sudo lfs hsm_state {} | grep released" > "$OUTPUT_FILE"
   
   echo "Search complete. Released objects are listed in $OUTPUT_FILE"
   echo "Total number of released objects: $(wc -l <"$OUTPUT_FILE")"
   ```

1. Machen Sie das Skript ausführbar:

   ```
   $ chmod +x find_lustre_released_files.sh
   ```

1. Führen Sie das Skript wie im folgenden Beispiel aus:

   ```
   $ ./find_lustre_released_files.sh /fsxl/sample
   Searching in /fsxl/sample for all released objects using 16 threads
   This may take a while depending on the size of the filesystem...
   real 0m9.906s
   user 0m1.502s
   sys 0m5.653s
   Search complete. Released objects are listed in released_objects_20241121_184537.txt
   Total number of released objects: 30000
   ```

Wenn freigegebene Objekte vorhanden sind, führen Sie eine Massenwiederherstellung der gewünschten Verzeichnisse durch, in die die Dateien von S3 FSx für Lustre übertragen werden sollen, wie im folgenden Beispiel:

```
$ DIR=/path/to/lustre/mount
$ nohup find $DIR -type f -print0 | xargs -0 -n 1 -P 8 sudo lfs hsm_restore &
```

Beachten Sie, dass `hsm_restore` dies bei Millionen von Dateien eine Weile dauern kann.