A Lustre File Stripe Count Is a Data Layout, Not a Copy Count

Distinguish storage targets, servers and metadata

A shared AI storage offer can identify a large Lustre filesystem without explaining where one checkpoint file's bytes reside. Begin with the target and the file, rather than treating the filesystem total as the file's layout.

An object storage server, or OSS, serves storage volumes called object storage targets, or OSTs. A file's data objects reside on those targets. One server can serve several targets, so two OST identifiers establish neither two servers nor two physical drives.

The metadata service records names, permissions and file layouts on metadata targets, or MDTs. The layout supplies the map to the file's data objects. A count of metadata targets therefore answers a different question from a file-data stripe count.

These distinctions describe ordinary OST-backed file data. Broader Lustre features include Data on MDT, which can place a file's initial data component on an MDT. Identify the actual layout type before applying a simple OST-only interpretation.

References: [O1][M1][I1]

Read stripe count, stripe size and stripe offset together

For a simple nonmirrored layout using distinct OSTs, stripe count identifies how many targets share the file-data distribution. Stripe size is the contiguous amount assigned to one target before the distribution moves to the next. After the last target in the layout, the sequence returns to the first.

Stripe offset identifies the first OST's index. It is a target index, separate from a byte offset within the file. Obtain the actual ordered target list as well: the starting index alone does not identify every selected target.

Stripe size describes distribution, not the underlying storage allocation block size. Nor does one stripe-sized region establish one application request or one network operation. The useful interpretation is a map of bytes; request timing and execution need separate evidence.

References: [O1][I1][A1]

Follow a fictional 5 MiB file across two targets

Example LS-303 stipulates a fully populated 5 MiB file with one fixed, nonmirrored, round-robin layout: stripe count 2, stripe size 1 MiB and ordered targets A then B. One MiB is 1,048,576 bytes. Metadata, allocation overhead and underlying protection are outside this payload calculation.

Number the five consecutive 1 MiB chunks from 0 through 4. Chunk 0 covers file offsets from 0 up to, but excluding, 1 MiB and belongs to A. Chunk 1 covers 1 MiB up to 2 MiB and belongs to B. Chunk 2 covers 2 MiB up to 3 MiB and returns to A. Chunk 3 covers 3 MiB up to 4 MiB on B. Chunk 4 covers 4 MiB up to 5 MiB on A.

A therefore holds 3 MiB of the file's payload and B holds 2 MiB. Together they account for the original 5 MiB. They do not hold two complete 5 MiB copies. Equal stripe size also does not require equal payload totals when the file ends partway through a distribution cycle.

The same map shows why the requested range matters. A read confined to chunk 0 addresses payload on A; reading the entire file involves payload assigned to both targets. The map supplies no request count, concurrency or elapsed time, and it cannot be applied unchanged to progressive or mirrored layouts.

References: [O1][U1]

Separate an existing file from a directory policy

A directory can carry a default file-data layout for files created within it when no overriding file layout is specified. Each file still receives its own objects and layout. The directory is not one large data object whose stripe count proves how every existing child file is distributed.

Ask whether the supplier's evidence describes the named existing file or the policy for creating future files. A later change to the directory default does not redistribute existing file contents. A policy report alone therefore leaves the delivered layout of an older checkpoint unresolved.

There is also a separate metadata meaning of directory striping in Lustre's distributed namespace: directory entries can be spread across MDTs. That is different from a directory's default policy for child-file data on OSTs. A statement such as this directory uses four stripes needs its target type and purpose identified before it supports a file-data claim.

References: [C1][M1]

Read a progressive layout one component at a time

A progressive file layout, or PFL, contains components covering consecutive, nonoverlapping file-offset ranges. Each component has its own layout parameters. Locate the requested byte range first, then read the stripe size, count and target objects for the component that covers it.

A later component with a wider layout does not make the earlier bytes follow that later layout. Growth can activate components already defined in the file's layout; that differs from replacing its layout with a new directory default.

Do not add component stripe counts and call the result a count of complete copies or distinct OSTs. Target sets can overlap across components. Read the component boundaries and actual target assignments to understand distribution across the file.

Lustre also supports file-level mirroring as a separate layout feature. Components describing disjoint byte ranges and mirrors describing copies answer different questions. The simple LS-303 example stipulates no mirroring; neither its target count nor a PFL component count identifies any protection beneath the targets.

References: [P1][I1]

Use FSx defaults as dated context

Amazon FSx for Lustre provides a named implementation. Its user guide, checked on 20 October 2026, associates a four-component default progressive layout with filesystems created after August 25, 2023. It documents earlier defaults and separate layout handling for S3-imported files and files created in append mode.

Those qualifications matter when reading an offer. A current default description does not establish the layout of an existing file, an imported file or a file created under a different policy. Request the delivered file's layout and creation context rather than assigning the latest documented default to every file on the service.

References: [A1]

Compare one large checkpoint with many independent files

A single large checkpoint file and a collection of independent dataset files can use the same filesystem differently. For the checkpoint, the file's own layout determines which targets hold the requested byte ranges. Available targets outside that layout do not automatically participate in serving those ranges.

Across a collection, files can have different target assignments. Many files can therefore distribute work across the filesystem even when each file individually uses a narrow layout. This requires the application's actual accesses to reach those files and targets; the file count alone establishes no concurrent work.

Neither pattern makes the largest stripe count a universal choice. Lustre's striping guidance distinguishes parallel access to one shared file from parallel access to separate files. AWS also identifies client networking and storage/cache paths as performance constraints. More target assignments do not by themselves establish a speedup.

For a checkpoint offer, ask for the named file's layout and evidence for the required access pattern. For a dataset offer, ask which files are accessed together and how their layouts distribute that work. Keep measured throughput, client configuration and workload conditions attached to the claim. The related IOPS, throughput and latency guide develops that performance comparison.

References: [C1][A1]

Return the offer to a file-level description

A useful supplier response identifies the file or representative file population, its layout type, component ranges where applicable, stripe sizes and counts, and actual target assignments. It distinguishes existing-file evidence from a policy proposed for new files. Retain the filesystem implementation, relevant version or service context and evidence date.

Keep three conclusions separate. The layout describes where file ranges are distributed. Capacity evidence describes how much data the specified allocation can hold. Protection evidence describes what is retained and under which failure conditions. A filesystem-wide capacity total cannot fill in the other two descriptions.

If an offer supplies only total capacity and a stripe count, it still leaves the buyer's one-file throughput and protection requirements unanswered. Request the missing evidence from the storage provider. The related capacity and checkpoint guides address their own decisions without turning this layout explanation into a tuning or recovery procedure.

Connect a physical installation only where the project needs one

Selecting FSx does not itself create an onsite storage-rack installation package. Where the wider project also includes customer-furnished servers, storage equipment or switches, the rack-and-stack service linked below covers agreed physical mounting, IT cabling, labels and installation records.

Use its project inquiry to share a nonconfidential equipment summary, released rack positions, approved connection schedule, site constraints and required physical handoff. Identify the appointed storage owner. Storage architecture, layout changes, tuning, data recovery and application operation require their own separately appointed scope.

References: [L1]