<para>
<emphasis>Aggregate:</emphasis>
</para>
- <para>10 TB/sec I/O</para>
+ <para>50 TB/sec I/O, 50M IOPS</para>
</entry>
<entry>
<para>
<emphasis>Single client:</emphasis>
</para>
- <para>4.5 GB/sec I/O (FDR IB, OPA1),
- 1000 metadata ops/sec</para>
+ <para>15 GB/sec I/O (HDR IB), 50000 IOPS</para>
<para>
<emphasis>Aggregate:</emphasis>
</para>
- <para>2.5 TB/sec I/O </para>
+ <para>10 TB/sec I/O, 10M IOPS</para>
</entry>
</row>
<row>
<para>
<emphasis>Single OST:</emphasis>
</para>
- <para>300M objects, 256TiB per OST (ldiskfs)</para>
- <para>500M objects, 256TiB per OST (ZFS)</para>
+ <para>500M objects, 1024TiB per OST</para>
<para>
<emphasis>OSS count:</emphasis>
</para>
- <para>1000 OSSs, with up to 4000 OSTs</para>
+ <para>1000 OSSs, 4000 OSTs</para>
</entry>
<entry>
<para>
<emphasis>Single OSS:</emphasis>
</para>
- <para>32x 8TiB OSTs per OSS (ldiskfs),</para>
- <para>8x 32TiB OSTs per OSS (ldiskfs)</para>
- <para>1x 72TiB OST per OSS (ZFS)</para>
+ <para>4 OSTs per OSS</para>
+ <para>
+ <emphasis>Single OST:</emphasis>
+ </para>
+ <para>1024TiB OSTs</para>
<para>
<emphasis>OSS count:</emphasis>
</para>
- <para>450 OSSs with 1000 4TiB OSTs</para>
- <para>192 OSSs with 1344 8TiB OSTs</para>
- <para>768 OSSs with 768 72TiB OSTs</para>
+ <para>450 OSSs with 900 750TiB HDD OSTs + 450 25TiB NVMe OSTs</para>
+ <para>1024 OSSs with 1024 72TiB OSTs</para>
</entry>
</row>
<row>
<para>
<emphasis>Single OSS:</emphasis>
</para>
- <para>15 GB/sec</para>
+ <para>15 GB/sec, 1.5M IOPS</para>
<para>
<emphasis>Aggregate:</emphasis>
</para>
- <para>10 TB/sec</para>
+ <para>50 TB/sec, 50M IOPS</para>
</entry>
<entry>
<para>
<emphasis>Single OSS:</emphasis>
</para>
- <para>10 GB/sec</para>
+ <para>10 GB/sec, 1.5M IOPS</para>
<para>
<emphasis>Aggregate:</emphasis>
</para>
- <para>2.5 TB/sec</para>
+ <para>20 TB/sec, 20M IOPS</para>
</entry>
</row>
<row>
<para>
<emphasis>Single MDT:</emphasis>
</para>
- <para>4 billion files, 8TiB per MDT (ldiskfs)</para>
+ <para>4 billion files, 16TiB per MDT (ldiskfs)</para>
<para>64 billion files, 64TiB per MDT (ZFS)</para>
<para>
<emphasis>MDS count:</emphasis>
</para>
- <para>256 MDSs, with up to 256 MDTs</para>
+ <para>256 MDSs, up to 256 MDTs</para>
</entry>
<entry>
<para>
<emphasis>Single MDS:</emphasis>
</para>
- <para>3 billion files</para>
+ <para>4 billion files</para>
<para>
<emphasis>MDS count:</emphasis>
</para>
- <para>7 MDS with 7 2TiB MDTs in production</para>
+ <para>40 MDS with 40 4TiB MDTs in production</para>
<para>256 MDS with 256 64GiB MDTs in testing</para>
</entry>
</row>
</para>
</entry>
<entry>
- <para>50000/s create operations,</para>
- <para>200000/s metadata stat operations</para>
+ <para>1M/s create operations</para>
+ <para>2M/s stat operations</para>
</entry>
<entry>
- <para>15000/s create operations,</para>
- <para>50000/s metadata stat operations</para>
+ <para>100k/s create operations,</para>
+ <para>200k/s metadata stat operations</para>
</entry>
</row>
<row>
<para>
<emphasis>Aggregate:</emphasis>
</para>
- <para>55 PiB space, 8 billion files</para>
+ <para>700 PiB space, 25 billion files</para>
</entry>
</row>
</tbody>
<listitem>
<para>Verifies the linkEA entry for each inode and regenerates it if
invalid or missing. The <emphasis role="italic">linkEA</emphasis>
- stores of the file name and parent FID. It is stored as an extended
+ stores the file name and parent FID. It is stored as an extended
attribute in each inode. Thus, the linkEA can be used to
reconstruct the full path name of a file from only the FID.</para>
</listitem>
<emphasis role="italic">striped</emphasis> across the objects using RAID 0,
and each object is stored on a different OST. (For more information about
how striping is implemented in a Lustre file system, see
- <xref linkend="dbdoclet.50438250_89922" />.</para>
+ <xref linkend="lustre_striping" />.</para>
<figure xml:id="Fig1.3_LayoutEAonMDT">
<title>Layout EA on MDT pointing to file data on OSTs</title>
<mediaobject>
available space of all the OSTs.</para>
</listitem>
</itemizedlist>
- <section xml:id="dbdoclet.50438250_89922">
+ <section xml:id="lustre_striping">
<title>
<indexterm>
<primary>Lustre</primary>
to utilize the full file system bandwidth.</para>
<para>For more information about striping, see
<xref linkend="managingstripingfreespace" />.</para>
+ <para>
+ <emphasis role="bold">Extended Attributes(xattrs)</emphasis></para>
+ <para>Lustre uses lov_user_md_v1/lov_user_md_v3 data-structures to
+ maintain its file striping information under xattrs. Extended
+ attributes are created when files and directory are created. Lustre
+ uses <literal>trusted</literal> extended attributes to store its
+ parameters which are root-only accessible. The parameters are:</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <emphasis role="bold"><literal>trusted.lov</literal>:</emphasis>
+ Holds layout for a regular file, or default file layout stored
+ on a directory (also accessible as <literal>lustre.lov</literal>
+ for non-root users).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold"><literal>trusted.lma</literal>:</emphasis>
+ Holds FID and extra state flags for current file</para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold"><literal>trusted.lmv</literal>:</emphasis>
+ Holds layout for a striped directory (DNE 2), not present otherwise
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold"><literal>trusted.link</literal>:</emphasis>
+ Holds parent directory FID + filename for each link to a file
+ (for <literal>lfs fid2path</literal>)</para>
+ </listitem>
+ </itemizedlist>
+ <para>xattr which are stored and present in the file could be verify
+ using:</para>
+ <para><screen># getfattr -d -m - /mnt/testfs/file></screen></para>
</section>
</section>
</chapter>
<!--
- vim:expandtab:shiftwidth=2:tabstop=8:
+ vim:expandtab:shiftwidth=2:tabstop=8:textwidth=80:
-->
git://git.whamcloud.com / doc / manual.git / blobdiff