Shared file system access across many VMs
managed file storage trade-offs.
use a managed NFS service like EFS or Filestore; watch per-operation latency, throughput modes, and metadata-heavy small-file workloads.
What's really being asked
The interviewer is checking that you reach for a managed file service for shared access and understand its performance envelope at scale.
The full answer
For a hierarchical file system multiple instances mount at once, use a managed network file service: EFS on AWS, Filestore on GCP, or Azure Files. These speak NFS or SMB, scale capacity automatically or by tier, and give POSIX semantics so existing apps work unchanged. The challenges appear at scale. Each operation crosses the network, so latency is higher than local or block storage, which hurts chatty, latency-sensitive workloads. Throughput depends on the mode: some services scale throughput with stored data or offer a provisioned-throughput option, and bursting modes can throttle. Metadata-heavy workloads, like listing or stat-ing millions of small files, are especially slow because each is a network round trip. Consistency is generally close-to-open under NFS, so concurrent writers to the same file need application-level coordination.
The mistakes people make
Using a single block volume and trying to share it across instances. Expecting local SSD latency from a network file system. Ignoring that small-file and metadata-heavy workloads dominate latency. Assuming throughput is unlimited rather than tied to a mode or provisioned setting.
What usually comes next
How do bursting versus provisioned throughput modes differ. How would you speed up a small-file workload, for example by packing files. What consistency guarantees does NFS provide for concurrent writers. When would object storage be a better fit.
A concrete example
A media render farm of fifty instances must read shared assets and write outputs to a common tree. The team mounts a managed NFS file system on every node. They hit slow directory listings because thousands of tiny intermediate files create metadata pressure, so they switch to provisioned throughput and restructure the pipeline to write fewer, larger files, restoring acceptable performance across the fleet.
Interview question
What workload pattern most degrades performance on a managed shared network file system at scale?
- a.Mounting the file system from more than one availability zone
- b.Sequential writes from a single instance
- c.Streaming reads of a few very large files
- d.Metadata-heavy access to millions of tiny filesCorrect
Why? this is the answer
Each metadata operation on a small file is a network round trip, so millions of tiny files cause severe latency. Large sequential streaming and single-writer workloads are exactly what network file systems handle well.
Just read this? Test yourself on what you have been reading.
Read the original → docs.aws.amazon.com
- #file-storage
- #nfs
- #efs
- #shared-storage
- #performance
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles