<para>Lustre clients running on architectures with different endianness are supported. One limitation is that the PAGE_SIZE kernel macro on the client must be as large as the PAGE_SIZE of the server. In particular, ia64 or PPC clients with large pages (up to 64kB pages) can run with x86 servers (4kB pages). If you are running x86 clients with ia64 or PPC servers, you must compile the ia64 kernel with a 4kB PAGE_SIZE (so the server page size is not larger than the client page size). </para>
</note>
<section remap="h3">
- <title><indexterm><primary>setup</primary><secondary>MDT</secondary></indexterm>
- MDT Storage Hardware Considerations</title>
- <para>The data access pattern for MDS storage is a database-like access pattern with many seeks and read-and-writes of small amounts of data. High throughput to MDS storage is not important. Storage types that provide much lower seek times, such as high-RPM SAS or SSD drives can be used for the MDT.</para>
+ <title><indexterm>
+ <primary>setup</primary>
+ <secondary>MDT</secondary>
+ </indexterm> MGT and MDT Storage Hardware Considerations</title>
+ <para>MGT storage requirements are small (less than 100 MB even in the largest Lustre file
+ systems), and the data on an MGT is only accessed on a server/client mount, so disk
+ performance is not a consideration. However, this data is vital for file system access, so
+ the MGT should be reliable storage, preferably mirrored RAID1.</para>
+ <para>MDS storage is accessed in a database-like access pattern with many seeks and
+ read-and-writes of small amounts of data. High throughput to MDS storage is not important.
+ Storage types that provide much lower seek times, such as high-RPM SAS or SSD drives can be
+ used for the MDT.</para>
<para>For maximum performance, the MDT should be configured as RAID1 with an internal journal and two disks from different controllers.</para>
<para>If you need a larger MDT, create multiple RAID1 devices from pairs of disks, and then make a RAID0 array of the RAID1 devices. This ensures maximum reliability because multiple disk failures only have a small chance of hitting both disks in the same RAID1 device.</para>
<para>Doing the opposite (RAID1 of a pair of RAID0 devices) has a 50% chance that even two disk failures can cause the loss of the whole MDT device. The first failure disables an entire half of the mirror and the second failure has a 50% chance of disabling the remaining mirror.</para>
<title><indexterm><primary>setup</primary><secondary>space</secondary></indexterm>
<indexterm><primary>space</primary><secondary>determining requirements</secondary></indexterm>
Determining Space Requirements</title>
- <para>The desired performance characteristics of the backing file systems on the MDT and OSTs are independent of one another. The size of the MDT backing file system depends on the number of inodes needed in the total Lustre file system, while the aggregate OST space depends on the total amount of data stored on the file system.</para>
+ <para>The desired performance characteristics of the backing file systems on the MDT and OSTs
+ are independent of one another. The size of the MDT backing file system depends on the number
+ of inodes needed in the total Lustre file system, while the aggregate OST space depends on the
+ total amount of data stored on the file system. If MGS data is to be stored on the MDT device
+ (co-located MGT and MDT), add 100 MB to the required size estimate for the MDT.</para>
<para>Each time a file is created on a Lustre file system, it consumes one inode on the MDT and one inode for each OST object over which the file is striped. Normally, each file's stripe count is based on the system-wide default stripe count. However, this can be changed for individual files using the <literal>lfs setstripe</literal> option. For more details, see <xref linkend="managingstripingfreespace"/>.</para>
<para>In a Lustre ldiskfs file system, all the inodes are allocated on the MDT and OSTs when the file system is first formatted. The total number of inodes on a formatted MDT or OST cannot be easily changed, although it is possible to add OSTs with additional space and corresponding inodes. Thus, the number of inodes created at format time should be generous enough to anticipate future expansion.</para>
<para>When the file system is in use and a file is created, the metadata associated with that file is stored in one of the pre-allocated inodes and does not consume any of the free space used to store file data.</para>
unusable for general storage. Thus, at least 400 MB of space is used on each OST before any
file object data is saved.</para>
</note>
+ <section>
+ <title><indexterm>
+ <primary>setup</primary>
+ <secondary>MGT</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>space</primary>
+ <secondary>determining MGT requirements</secondary>
+ </indexterm> Determining MGT Space Requirements</title>
+ <para>Less than 100 MB of space is required for the MGT. The size is determined by the number
+ of servers in the Lustre cluster(s) that are managed by the MGS.</para>
+ </section>
<section xml:id="dbdoclet.50438256_87676">
- <title><indexterm><primary>setup</primary><secondary>MDS/MDT</secondary></indexterm>
- <indexterm><primary>space</primary><secondary>determining MDS/MDT requirements</secondary></indexterm>
- Determining MDS/MDT Space Requirements</title>
+ <title><indexterm>
+ <primary>setup</primary>
+ <secondary>MDT</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>space</primary>
+ <secondary>determining MDT requirements</secondary>
+ </indexterm> Determining MDT Space Requirements</title>
<para>When calculating the MDT size, the important factor to consider is the number of files to be stored in the file system. This determines the number of inodes needed, which drives the MDT sizing. To be on the safe side, plan for 2 KB per inode on the MDT, which is the default value. Attached storage required for Lustre metadata is typically 1-2 percent of the file system capacity depending upon file size.</para>
<para>For example, if the average file size is 5 MB and you have 100 TB of usable OST space, then you can calculate the minimum number of inodes as follows:</para>
<informalexample>
</note>
</section>
<section remap="h3">
- <title><indexterm><primary>setup</primary><secondary>OSS/OST</secondary></indexterm>
- <indexterm><primary>space</primary><secondary>determining OSS/OST requirements</secondary></indexterm>
- Determining OSS/OST Space Requirements</title>
+ <title><indexterm>
+ <primary>setup</primary>
+ <secondary>OST</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>space</primary>
+ <secondary>determining OST requirements</secondary>
+ </indexterm> Determining OST Space Requirements</title>
<para>For the OST, the amount of space taken by each object depends on the usage pattern of
the users/applications running on the system. The Lustre software defaults to a conservative
estimate for the object size (16 KB per object). If you are confident that the average file
git://git.whamcloud.com / doc / manual.git / commitdiff