AWS fsx documentation change
Summary
Added clarification about clean unmount procedures using `umount` without `-f` or `-l`, explained consequences of unclean unmounts (increased latency, hanging operations, I/O errors), and added note about unmount timing with many file systems on Spot Instances.
Security assessment
The changes provide operational guidance for clean unmounting to avoid performance issues and data corruption, but there's no evidence of addressing a specific security vulnerability. The mention of 'protect the file system against misbehaving clients' refers to existing eviction mechanisms, not new security fixes.
Diff
diff --git a/fsx/latest/LustreGuide/working-with-ec2-spot-instances.md b/fsx/latest/LustreGuide/working-with-ec2-spot-instances.md index 062f9f9f6..7ec19f5de 100644 --- a//fsx/latest/LustreGuide/working-with-ec2-spot-instances.md +++ b//fsx/latest/LustreGuide/working-with-ec2-spot-instances.md @@ -17 +17,3 @@ To ensure that Amazon FSx file systems are unaffected by EC2 Spot Instances Inte -FSx for Lustre is a distributed file system where server and client instances cooperate to provide a performant and reliable file system. They maintain a distributed and coherent state across both client and server instances. FSx for Lustre servers delegate temporary access permissions to clients while they are actively doing I/O and caching file system data. Clients are expected to reply in a short period of time when servers request them to revoke their temporary access permissions. To protect the file system against misbehaving clients, servers can evict Lustre clients that do not respond after a few minutes. To avoid having to wait multiple minutes for a non-responding client to reply to the server request, it is important to cleanly unmount Lustre clients, especially before terminating EC2 Spot Instances. +FSx for Lustre is a distributed file system where server and client instances cooperate to provide a performant and reliable file system. They maintain a distributed and coherent state across both client and server instances. FSx for Lustre servers delegate temporary access permissions to clients while they are actively doing I/O and caching file system data. Clients are expected to reply in a short period of time when servers request them to revoke their temporary access permissions. To protect the file system against misbehaving clients, servers can evict Lustre clients that do not respond after a few minutes. To avoid having to wait multiple minutes for a non-responding client to reply to the server request, it is important to cleanly unmount Lustre clients, especially before terminating EC2 Spot Instances. A clean unmount is initiated by using the `umount` command without `-f` or `-l`. + +If Lustre clients are shut down without cleanly unmounting the file system, other clients using that file system are likely to experience temporarily increased latency, hanging operations, or I/O errors. @@ -37,0 +40,4 @@ You can adapt the script as needed, especially for gracefully shutting down your +###### Note + +It can take time for a Lustre client to unmount a file system. If you mount many file systems on the same Amazon EC2 Spot Instance, it may take too long to unmount all of them within the two-minute Spot termination notice window. If you need to mount a large number of file systems on one host, we recommend using On-Demand Instances to avoid issues with unclean unmounts due to Amazon EC2 Spot Instance interruptions. +