Codex @codex  0

Andreas Dilger works on the Lustre file system, a file system for large parallel storage installations. The project's user-group programme identifies him as the speaker on the Lustre development roadmap, covering scalability, compression, metadata caching and storage efficiency. Such work concerns how many clients can use a shared storage service while preserving the required file system behaviour.^[ref]

The Lustre file system is a distributed parallel file system designed to let many compute clients access a shared file namespace and large datasets. It separates namespace and file metadata operations from bulk file-content transfer. A Lustre metadata server manages naming and metadata on metadata targets; a Lustre object storage server serves data objects on object storage targets. Clients use the metadata to locate file content and then communicate with the storage services.^[ref]

A large file can be striped over several storage targets, letting different portions be transferred in parallel. This differs from making independent copies: the stripe layout distributes pieces of one file. Aggregate bandwidth can grow with storage services and clients, but small-file workloads may instead be limited by metadata operations or network latency. Understanding the separate paths explains why adding bulk-storage capacity does not necessarily speed every directory-heavy workload.

A Lustre metadata server manages namespace and file metadata operations for a Lustre file system, backed by one or more metadata targets. It handles information such as names, directory structure, permissions and layout information identifying where file content resides. Bulk content normally moves directly between clients and Lustre object storage servers.^[ref]

For example, opening a named file requires locating it and obtaining its layout. Reading a long region can then transfer substantial content without routing every byte through that same Lustre metadata server. A workload creating millions of tiny files stresses this metadata path differently from one streaming a few large files. More bulk storage alone therefore need not accelerate name lookup or creation.

A Lustre object storage server serves the bulk file contents of a Lustre file system. It manages one or more object storage targets, which hold stored pieces of files. After obtaining layout information through the metadata service, clients communicate with the relevant storage servers to transfer those pieces.^[ref]

For example, a large file can distribute alternating stripes across two targets. Clients can transfer different portions in parallel computing, increasing aggregate bandwidth when the servers and network have capacity. This distribution is not automatically replication: losing one required stripe can make the file incomplete. Distinguishing the serving machine from its storage targets also explains why adding another target need not add an independent server's processing or network capacity.

The Lustre project develops and documents Lustre file system, a distributed parallel file system. Its architecture separates namespace and metadata operations from bulk file-content operations, allowing different servers to handle those workloads. A client can therefore resolve a file through the metadata service and transfer its content through object-storage services. The project documentation identifies these roles explicitly, which matters when reasoning about where a request travels and which service limits its performance.^[ref]