ManagingStripingFreeSpace.xml

   1 <?xml version='1.0' encoding='UTF-8'?><chapter xmlns="http://docbook.org/ns/docbook" xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en-US" xml:id="managingstripingfreespace">
   2   <title xml:id="managingstripingfreespace.title">Managing File Layout (Striping) and Free
   3     Space</title>
   4   <para>This chapter describes file layout (striping) and I/O options, and includes the following
   5     sections:</para>
   6   <itemizedlist>
   7     <listitem>
   8       <para><xref linkend="dbdoclet.50438209_79324"/></para>
   9     </listitem>
  10     <listitem>
  11       <para><xref linkend="dbdoclet.50438209_48033"/></para>
  12     </listitem>
  13     <listitem>
  14       <para><xref linkend="dbdoclet.50438209_78664"/></para>
  15     </listitem>
  16     <listitem>
  17       <para><xref linkend="dbdoclet.50438209_44776"/></para>
  18     </listitem>
  19     <listitem>
  20       <para><xref linkend="dbdoclet.50438209_10424"/></para>
  21     </listitem>
  22     <listitem>
  23       <para><xref xmlns:xlink="http://www.w3.org/1999/xlink" linkend="wide_striping"/></para>
  24     </listitem>
  25   </itemizedlist>
  26   <section xml:id="dbdoclet.50438209_79324">
  27       <title>
  28       <indexterm>
  29         <primary>space</primary>
  30       </indexterm>
  31       <indexterm>
  32         <primary>striping</primary>
  33         <secondary>how it works</secondary>
  34       </indexterm>
  35       <indexterm>
  36         <primary>striping</primary>
  37         <see>space</see>
  38       </indexterm>
  39       <indexterm>
  40         <primary>space</primary>
  41         <secondary>striping</secondary>
  42       </indexterm>How Lustre File System Striping Works</title>
  43     <para>In a Lustre file system, the MDS allocates objects to OSTs using either a round-robin
  44       algorithm or a weighted algorithm. When the amount of free space is well balanced (i.e., by
  45       default, when the free space across OSTs differs by less than 17%), the round-robin algorithm
  46       is used to select the next OST to which a stripe is to be written. Periodically, the MDS
  47       adjusts the striping layout to eliminate some degenerated cases in which applications that
  48       create very regular file layouts (striping patterns) preferentially use a particular OST in
  49       the sequence.</para>
  50     <para> Normally the usage of OSTs is well balanced. However, if users create a small number of
  51       exceptionally large files or incorrectly specify striping parameters, imbalanced OST usage may
  52       result. When the free space across OSTs differs by more than a specific amount (17% by
  53       default), the MDS then uses weighted random allocations with a preference for allocating
  54       objects on OSTs with more free space. (This can reduce I/O performance until space usage is
  55       rebalanced again.) For a more detailed description of how striping is allocated, see <xref
  56         linkend="dbdoclet.50438209_10424"/>.</para>
  57     <para>Files can only be striped over a finite number of OSTs, based on the
  58     maximum size of the attributes that can be stored on the MDT. If the MDT
  59     is ldiskfs-based without the <literal>ea_inode</literal> feature, a file
  60     can be striped across at most 160 OSTs.  With a ZFS-based MDT, or if the
  61     <literal>ea_inode</literal> feature is enabled for an ldiskfs-based MDT,
  62     a file can be striped across up to 2000 OSTs. For more information, see
  63     <xref xmlns:xlink="http://www.w3.org/1999/xlink" linkend="wide_striping"/>.
  64     </para>
  65   </section>
  66   <section xml:id="dbdoclet.50438209_48033">
  67       <title><indexterm>
  68         <primary>file layout</primary>
  69         <secondary>See striping</secondary>
  70       </indexterm><indexterm>
  71         <primary>striping</primary>
  72         <secondary>considerations</secondary>
  73       </indexterm>
  74       <indexterm>
  75         <primary>space</primary>
  76         <secondary>considerations</secondary>
  77       </indexterm> Lustre File Layout (Striping) Considerations</title>
  78     <para>Whether you should set up file striping and what parameter values you select depends on
  79       your needs. A good rule of thumb is to stripe over as few objects as will meet those needs and
  80       no more.</para>
  81     <para>Some reasons for using striping include:</para>
  82     <itemizedlist>
  83       <listitem>
  84         <para><emphasis role="bold">Providing high-bandwidth access.</emphasis> Many applications
  85           require high-bandwidth access to a single file, which may be more bandwidth than can be
  86           provided by a single OSS. Examples are a scientific application that writes to a single
  87           file from hundreds of nodes, or a binary executable that is loaded by many nodes when an
  88           application starts.</para>
  89         <para>In cases like these, a file can be striped over as many OSSs as it takes to achieve
  90           the required peak aggregate bandwidth for that file. Striping across a larger number of
  91           OSSs should only be used when the file size is very large and/or is accessed by many nodes
  92           at a time. Currently, Lustre files can be striped across up to 2000 OSTs, the maximum
  93           stripe count for an <literal>ldiskfs</literal> file system.</para>
  94       </listitem>
  95       <listitem>
  96         <para><emphasis role="bold">Improving performance when OSS bandwidth is exceeded.</emphasis>
  97           Striping across many OSSs can improve performance if the aggregate client bandwidth
  98           exceeds the server bandwidth and the application reads and writes data fast enough to take
  99           advantage of the additional OSS bandwidth. The largest useful stripe count is bounded by
 100           the I/O rate of the clients/jobs divided by the performance per OSS.</para>
 101       </listitem>
 102       <listitem>
 103         <para><emphasis role="bold">Providing space for very large files.</emphasis> Striping is
 104           useful when a single OST does not have enough free space to hold the entire file.</para>
 105       </listitem>
 106     </itemizedlist>
 107     <para>Some reasons to minimize or avoid striping:</para>
 108     <itemizedlist>
 109       <listitem>
 110         <para><emphasis role="bold">Increased overhead.</emphasis> Striping results in more locks
 111           and extra network operations during common operations such as <literal>stat</literal> and
 112             <literal>unlink</literal>. Even when these operations are performed in parallel, one
 113           network operation takes less time than 100 operations.</para>
 114         <para>Increased overhead also results from server contention. Consider a cluster with 100
 115           clients and 100 OSSs, each with one OST. If each file has exactly one object and the load
 116           is distributed evenly, there is no contention and the disks on each server can manage
 117           sequential I/O. If each file has 100 objects, then the clients all compete with one
 118           another for the attention of the servers, and the disks on each node seek in 100 different
 119           directions resulting in needless contention.</para>
 120       </listitem>
 121       <listitem>
 122         <para><emphasis role="bold">Increased risk.</emphasis> When files are striped across all
 123           servers and one of the servers breaks down, a small part of each striped file is lost. By
 124           comparison, if each file has exactly one stripe, fewer files are lost, but they are lost
 125           in their entirety. Many users would prefer to lose some of their files entirely than all
 126           of their files partially.</para>
 127       </listitem>
 128     </itemizedlist>
 129     <section remap="h3">
 130         <title><indexterm><primary>striping</primary><secondary>size</secondary></indexterm>
 131             Choosing a Stripe Size</title>
 132       <para>Choosing a stripe size is a balancing act, but reasonable defaults are described below.
 133         The stripe size has no effect on a single-stripe file.</para>
 134       <itemizedlist>
 135         <listitem>
 136           <para><emphasis role="bold">The stripe size must be a multiple of the page
 137               size.</emphasis> Lustre software tools enforce a multiple of 64 KB (the maximum page
 138             size on ia64 and PPC64 nodes) so that users on platforms with smaller pages do not
 139             accidentally create files that might cause problems for ia64 clients.</para>
 140         </listitem>
 141         <listitem>
 142           <para><emphasis role="bold">The smallest recommended stripe size is 512 KB.</emphasis>
 143             Although you can create files with a stripe size of 64 KB, the smallest practical stripe
 144             size is 512 KB because the Lustre file system sends 1MB chunks over the network.
 145             Choosing a smaller stripe size may result in inefficient I/O to the disks and reduced
 146             performance.</para>
 147         </listitem>
 148         <listitem>
 149           <para><emphasis role="bold">A good stripe size for sequential I/O using high-speed
 150               networks is between 1 MB and 4 MB.</emphasis> In most situations, stripe sizes larger
 151             than 4 MB may result in longer lock hold times and contention during shared file
 152             access.</para>
 153         </listitem>
 154         <listitem>
 155           <para><emphasis role="bold">The maximum stripe size is 4 GB.</emphasis> Using a large
 156             stripe size can improve performance when accessing very large files. It allows each
 157             client to have exclusive access to its own part of a file. However, a large stripe size
 158             can be counterproductive in cases where it does not match your I/O pattern.</para>
 159         </listitem>
 160         <listitem>
 161           <para><emphasis role="bold">Choose a stripe pattern that takes into account the write
 162               patterns of your application.</emphasis> Writes that cross an object boundary are
 163             slightly less efficient than writes that go entirely to one server. If the file is
 164             written in a consistent and aligned way, make the stripe size a multiple of the
 165               <literal>write()</literal> size.</para>
 166         </listitem>
 167       </itemizedlist>
 168     </section>
 169   </section>
 170   <section xml:id="dbdoclet.50438209_78664">
 171       <title><indexterm>
 172         <primary>striping</primary>
 173         <secondary>configuration</secondary>
 174       </indexterm>Setting the File Layout/Striping Configuration (<literal>lfs
 175       setstripe</literal>)</title>
 176     <para>Use the <literal>lfs setstripe</literal> command to create new files with a specific file layout (stripe pattern) configuration.</para>
 177     <screen>lfs setstripe [--size|-s stripe_size] [--count|-c stripe_count] \
 178 [--index|-i start_ost] [--pool|-p pool_name] <replaceable>filename|dirname</replaceable> </screen>
 179     <para><emphasis role="bold">
 180         <literal>stripe_size</literal>
 181       </emphasis>
 182       </para>
 183     <para>The <literal>stripe_size</literal> indicates how much data to write to one OST before
 184       moving to the next OST. The default <literal>stripe_size</literal> is 1 MB. Passing a
 185         <literal>stripe_size</literal> of 0 causes the default stripe size to be used. Otherwise,
 186       the <literal>stripe_size</literal> value must be a multiple of 64 KB.</para>
 187     <para><emphasis role="bold">
 188         <literal>stripe_count</literal>
 189       </emphasis>
 190       </para>
 191     <para>The <literal>stripe_count</literal> indicates how many OSTs to use. The default <literal>stripe_count</literal> value is 1. Setting <literal>stripe_count</literal> to 0 causes the default stripe count to be used. Setting <literal>stripe_count</literal> to -1 means stripe over all available OSTs (full OSTs are skipped).</para>
 192     <para><emphasis role="bold">
 193         <literal>start_ost</literal>
 194       </emphasis>
 195       </para>
 196     <para>The start OST is the first OST to which files are written. The default value for
 197         <literal>start_ost</literal> is -1, which allows the MDS to choose the starting index. This
 198       setting is strongly recommended, as it allows space and load balancing to be done by the MDS
 199       as needed. If the value of <literal>start_ost</literal> is set to a value other than -1, the
 200       file starts on the specified OST index. OST index numbering starts at 0.</para>
 201     <note>
 202       <para>If the specified OST is inactive or in a degraded mode, the MDS will silently choose
 203         another target.</para>
 204     </note>
 205     <note>
 206       <para>If you pass a <literal>start_ost</literal> value of 0 and a
 207           <literal>stripe_count</literal> value of <emphasis>1</emphasis>, all files are written to
 208         OST 0, until space is exhausted. <emphasis role="italic">This is probably not what you meant
 209           to do.</emphasis> If you only want to adjust the stripe count and keep the other
 210         parameters at their default settings, do not specify any of the other parameters:</para>
 211       <para><screen>client# lfs setstripe -c <replaceable>stripe_count</replaceable> <replaceable>filename</replaceable></screen></para>
 212     </note>
 213     <para><emphasis role="bold">
 214         <literal>pool_name</literal>
 215       </emphasis>
 216       </para>
 217     <para>The <literal>pool_name</literal> specifies the OST pool to which the file will be written.
 218       This allows limiting the OSTs used to a subset of all OSTs in the file system. For more
 219       details about using OST pools, see <link xl:href="ManagingFileSystemIO.html#50438211_75549"
 220         >Creating and Managing OST Pools</link>.</para>
 221     <section remap="h3">
 222       <title>Specifying a File Layout (Striping Pattern) for a Single File</title>
 223       <para>It is possible to specify the file layout when a new file is created using the command <literal>lfs setstripe</literal>. This allows users to override the file system default parameters to tune the file layout more optimally for their application. Execution of an <literal>lfs setstripe</literal> command fails if the file already exists.</para>
 224       <section xml:id="dbdoclet.50438209_60155">
 225         <title>Setting the Stripe Size</title>
 226         <para>The command to create a new file with a specified stripe size is similar to:</para>
 227         <screen>[client]# lfs setstripe -s 4M /mnt/lustre/new_file</screen>
 228         <para>This example command creates the new file <literal>/mnt/lustre/new_file</literal> with a stripe size of 4 MB.</para>
 229         <para>Now, when the file is created, the new stripe setting creates the file on a single OST with a stripe size of 4M:</para>
 230         <screen> [client]# lfs getstripe /mnt/lustre/new_file
 231 /mnt/lustre/4mb_file
 232 lmm_stripe_count:   1
 233 lmm_stripe_size:    4194304
 234 lmm_pattern:        1
 235 lmm_layout_gen:     0
 236 lmm_stripe_offset:  1
 237 obdidx     objid        objid           group
 238 1          690550       0xa8976         0 </screen>
 239         <para>In this example, the stripe size is 4 MB.</para>
 240       </section>
 241       <section remap="h4">
 242           <title><indexterm><primary>striping</primary><secondary>count</secondary></indexterm>
 243               Setting the Stripe Count</title>
 244         <para>The command below creates a new file with a stripe count of <literal>-1</literal> to
 245           specify striping over all available OSTs:</para>
 246         <screen>[client]# lfs setstripe -c -1 /mnt/lustre/full_stripe</screen>
 247         <para>The example below indicates that the file <literal>full_stripe</literal> is striped
 248           over all six active OSTs in the configuration:</para>
 249         <screen>[client]# lfs getstripe /mnt/lustre/full_stripe
 250 /mnt/lustre/full_stripe
 251   obdidx   objid   objid   group
 252   0        8       0x8     0
 253   1        4       0x4     0
 254   2        5       0x5     0
 255   3        5       0x5     0
 256   4        4       0x4     0
 257   5        2       0x2     0</screen>
 258         <para> This is in contrast to the output in <xref linkend="dbdoclet.50438209_60155"/>, which
 259           shows only a single object for the file.</para>
 260       </section>
 261     </section>
 262     <section remap="h3">
 263       <title><indexterm>
 264           <primary>striping</primary>
 265           <secondary>per directory</secondary>
 266         </indexterm>Setting the Striping Layout for a Directory</title>
 267       <para>In a directory, the <literal>lfs setstripe</literal> command sets a default striping
 268         configuration for files created in the directory. The usage is the same as <literal>lfs
 269           setstripe</literal> for a regular file, except that the directory must exist prior to
 270         setting the default striping configuration. If a file is created in a directory with a
 271         default stripe configuration (without otherwise specifying striping), the Lustre file system
 272         uses those striping parameters instead of the file system default for the new file.</para>
 273       <para>To change the striping pattern for a sub-directory, create a directory with desired file
 274         layout as described above. Sub-directories inherit the file layout of the root/parent
 275         directory.</para>
 276     </section>
 277     <section remap="h3">
 278       <title><indexterm>
 279           <primary>striping</primary>
 280           <secondary>per file system</secondary>
 281         </indexterm>Setting the Striping Layout for a File System</title>
 282       <para>Setting the striping specification on the <literal>root</literal> directory determines
 283         the striping for all new files created in the file system unless an overriding striping
 284         specification takes precedence (such as a striping layout specified by the application, or
 285         set using <literal>lfs setstripe</literal>, or specified for the parent directory).</para>
 286       <note>
 287         <para>The striping settings for a <literal>root</literal> directory are, by default, applied
 288           to any new child directories created in the root directory, unless striping settings have
 289           been specified for the child directory.</para>
 290       </note>
 291     </section>
 292     <section remap="h3">
 293       <title><indexterm>
 294           <primary>striping</primary>
 295           <secondary>on specific OST</secondary>
 296         </indexterm>Creating a File on a Specific OST</title>
 297       <para>You can use <literal>lfs setstripe</literal> to create a file on a specific OST. In the
 298         following example, the file <literal>file1</literal> is created on the first OST (OST index
 299         is 0).</para>
 300       <screen>$ lfs setstripe --count 1 --index 0 file1
 301 $ dd if=/dev/zero of=file1 count=1 bs=100M
 302 1+0 records in
 303 1+0 records out
 304
 305 $ lfs getstripe file1
 306 /mnt/testfs/file1
 307 lmm_stripe_count:   1
 308 lmm_stripe_size:    1048576
 309 lmm_pattern:        1
 310 lmm_layout_gen:     0
 311 lmm_stripe_offset:  0
 312      obdidx    objid   objid    group
 313      0         37364   0x91f4   0</screen>
 314     </section>
 315   </section>
 316   <section xml:id="dbdoclet.50438209_44776">
 317     <title><indexterm><primary>striping</primary><secondary>getting information</secondary></indexterm>Retrieving File Layout/Striping Information (<literal>getstripe</literal>)</title>
 318     <para>The <literal>lfs getstripe</literal> command is used to display information that shows
 319       over which OSTs a file is distributed. For each OST, the index and UUID is displayed, along
 320       with the OST index and object ID for each stripe in the file. For directories, the default
 321       settings for files created in that directory are displayed.</para>
 322     <section remap="h3">
 323       <title>Displaying the Current Stripe Size</title>
 324       <para>To see the current stripe size for a Lustre file or directory, use the <literal>lfs
 325           getstripe</literal> command. For example, to view information for a directory, enter a
 326         command similar to:</para>
 327       <screen>[client]# lfs getstripe /mnt/lustre </screen>
 328       <para>This command produces output similar to:</para>
 329       <screen>/mnt/lustre
 330 (Default) stripe_count: 1 stripe_size: 1M stripe_offset: -1</screen>
 331       <para>In this example, the default stripe count is <literal>1</literal> (data blocks are
 332         striped over a single OST), the default stripe size is 1 MB, and the objects are created
 333         over all available OSTs.</para>
 334       <para>To view information for a file, enter a command similar to:</para>
 335       <screen>$ lfs getstripe /mnt/lustre/foo
 336 /mnt/lustre/foo
 337 lmm_stripe_count:   1
 338 lmm_stripe_size:    1048576
 339 lmm_pattern:        1
 340 lmm_layout_gen:     0
 341 lmm_stripe_offset:  0
 342   obdidx   objid    objid      group
 343   2        835487   m0xcbf9f   0 </screen>
 344       <para>In this example, the file is located on <literal>obdidx 2</literal>, which corresponds
 345         to the OST <literal>lustre-OST0002</literal>. To see which node is serving that OST, run:
 346         <screen>$ lctl get_param osc.lustre-OST0002-osc.ost_conn_uuid
 347 osc.lustre-OST0002-osc.ost_conn_uuid=192.168.20.1@tcp</screen></para>
 348     </section>
 349     <section remap="h3">
 350       <title>Inspecting the File Tree</title>
 351       <para>To inspect an entire tree of files, use the <literal>lfs find</literal>  command:</para>
 352       <screen>lfs find [--recursive | -r] <replaceable>file|directory</replaceable> ...</screen>
 353     </section>
 354         <section>
 355       <title><indexterm>
 356           <primary>striping</primary>
 357           <secondary>remote directories</secondary>
 358         </indexterm>Locating the MDT for a remote directory</title>
 359       <para condition="l24">Lustre software release 2.4 can be configured with
 360           multiple MDTs in the same file system. Each sub-directory can have a
 361           different MDT. To identify on which MDT a given subdirectory is
 362           located, pass the <literal>getstripe [--mdt-index|-M]</literal>
 363           parameters to <literal>lfs</literal>. An example of this command is
 364           provided in the section <xref linkend="dbdoclet.rmremotedir"/>.</para>
 365     </section>
 366   </section>
 367   <section xml:id="dbdoclet.50438209_10424">
 368     <title><indexterm>
 369         <primary>space</primary>
 370         <secondary>free space</secondary>
 371       </indexterm><indexterm>
 372         <primary>striping</primary>
 373         <secondary>round-robin algorithm</secondary>
 374       </indexterm><indexterm>
 375         <primary>striping</primary>
 376         <secondary>weighted algorithm</secondary>
 377       </indexterm><indexterm>
 378         <primary>round-robin algorithm</primary>
 379       </indexterm><indexterm>
 380         <primary>weighted algorithm</primary>
 381       </indexterm>Managing Free Space</title>
 382     <para>To optimize file system performance, the MDT assigns file stripes to OSTs based on two
 383       allocation algorithms. The <emphasis role="italic">round-robin</emphasis> allocator gives
 384       preference to location (spreading out stripes across OSSs to increase network bandwidth
 385       utilization) and the weighted allocator gives preference to available space (balancing loads
 386       across OSTs). Threshold and weighting factors for these two algorithms can be adjusted by the
 387       user. The MDT reserves 0.1 percent of total OST space and 32 inodes for each OST. The MDT
 388       stops object allocation for the OST if available space is less than reserved or the OST has
 389       fewer than 32 free inodes. The MDT starts object allocation when available space is twice
 390       as big as the reserved space and the OST has more than 64 free inodes. Note, clients
 391       could append existing files no matter what object allocation state is.</para>
 392     <para condition="l29"> The reserved space for each OST can be adjusted by the user. Use the
 393       <literal>lctl set_param</literal> command, for example the next command reserve 1GB space
 394       for all OSTs.
 395       <screen>lctl set_param -P osp.*.reserved_mb_low=1024</screen></para>
 396     <para>This section describes how to check available free space on disks and how free space is
 397       allocated. It then describes how to set the threshold and weighting factors for the allocation
 398       algorithms.</para>
 399     <section xml:id="dbdoclet.50438209_35838">
 400       <title>Checking File System Free Space</title>
 401       <para>Free space is an important consideration in assigning file stripes. The <literal>lfs
 402           df</literal> command can be used to show available disk space on the mounted Lustre file
 403         system and space consumption per OST. If multiple Lustre file systems are mounted, a path
 404         may be specified, but is not required. Options to the <literal>lfs df</literal> command are
 405         shown below.</para>
 406       <informaltable frame="all">
 407         <tgroup cols="2">
 408           <colspec colname="c1" colwidth="50*"/>
 409           <colspec colname="c2" colwidth="50*"/>
 410           <thead>
 411             <row>
 412               <entry>
 413                 <para><emphasis role="bold">Option</emphasis></para>
 414               </entry>
 415               <entry>
 416                 <para><emphasis role="bold">Description</emphasis></para>
 417               </entry>
 418             </row>
 419           </thead>
 420           <tbody>
 421             <row>
 422               <entry>
 423                 <para> <literal>-h</literal></para>
 424               </entry>
 425               <entry>
 426                 <para> Displays sizes in human readable format (for example: 1K, 234M, 5G).</para>
 427               </entry>
 428             </row>
 429             <row>
 430               <entry>
 431                 <para> <literal role="bold">-i, --inodes</literal></para>
 432               </entry>
 433               <entry>
 434                 <para> Lists inodes instead of block usage.</para>
 435               </entry>
 436             </row>
 437           </tbody>
 438         </tgroup>
 439       </informaltable>
 440       <note>
 441         <para>The <literal>df -i</literal> and <literal>lfs df -i</literal> commands show the
 442             <emphasis role="italic">minimum</emphasis> number of inodes that can be created in the
 443           file system at the current time. If the total number of objects available across all of
 444           the OSTs is smaller than those available on the MDT(s), taking into account the default
 445           file striping, then <literal>df -i</literal> will also report a smaller number of inodes
 446           than could be created. Running <literal>lfs df -i</literal> will report the actual number
 447           of inodes that are free on each target.</para>
 448         <para>For ZFS file systems, the number of inodes that can be created is dynamic and depends
 449           on the free space in the file system. The Free and Total inode counts reported for a ZFS
 450           file system are only an estimate based on the current usage for each target. The Used
 451           inode count is the actual number of inodes used by the file system.</para>
 452       </note>
 453       <para><emphasis role="bold">Examples</emphasis></para>
 454       <screen>[client1] $ lfs df
 455 UUID                1K-blockS  Used      Available Use% Mounted on
 456 mds-lustre-0_UUID   9174328    1020024   8154304   11%  /mnt/lustre[MDT:0]
 457 ost-lustre-0_UUID   94181368   56330708  37850660  59%  /mnt/lustre[OST:0]
 458 ost-lustre-1_UUID   94181368   56385748  37795620  59%  /mnt/lustre[OST:1]
 459 ost-lustre-2_UUID   94181368   54352012  39829356  57%  /mnt/lustre[OST:2]
 460 filesystem summary: 282544104  167068468 39829356  57%  /mnt/lustre
 461
 462 [client1] $ lfs df -h
 463 UUID                bytes    Used    Available   Use%  Mounted on
 464 mds-lustre-0_UUID   8.7G     996.1M  7.8G        11%   /mnt/lustre[MDT:0]
 465 ost-lustre-0_UUID   89.8G    53.7G   36.1G       59%   /mnt/lustre[OST:0]
 466 ost-lustre-1_UUID   89.8G    53.8G   36.0G       59%   /mnt/lustre[OST:1]
 467 ost-lustre-2_UUID   89.8G    51.8G   38.0G       57%   /mnt/lustre[OST:2]
 468 filesystem summary: 269.5G   159.3G  110.1G      59%   /mnt/lustre
 469
 470 [client1] $ lfs df -i
 471 UUID                Inodes  IUsed IFree   IUse% Mounted on
 472 mds-lustre-0_UUID   2211572 41924 2169648 1%    /mnt/lustre[MDT:0]
 473 ost-lustre-0_UUID   737280  12183 725097  1%    /mnt/lustre[OST:0]
 474 ost-lustre-1_UUID   737280  12232 725048  1%    /mnt/lustre[OST:1]
 475 ost-lustre-2_UUID   737280  12214 725066  1%    /mnt/lustre[OST:2]
 476 filesystem summary: 2211572 41924 2169648 1%    /mnt/lustre[OST:2]</screen>
 477     </section>
 478     <section remap="h3">
 479         <title><indexterm>
 480           <primary>striping</primary>
 481           <secondary>allocations</secondary>
 482         </indexterm> Stripe Allocation Methods</title>
 483       <para>Two stripe allocation methods are provided:</para>
 484       <itemizedlist>
 485         <listitem>
 486           <para><emphasis role="bold">Round-robin allocator</emphasis> - When the OSTs have
 487             approximately the same amount of free space, the round-robin allocator alternates
 488             stripes between OSTs on different OSSs, so the OST used for stripe 0 of each file is
 489             evenly distributed among OSTs, regardless of the stripe count. In a simple example with
 490             eight OSTs numbered 0-7, objects would be allocated like this:</para>
 491           <para>
 492             <screen>File 1: OST1, OST2, OST3, OST4
 493 File 2: OST5, OST6, OST7
 494 File 3: OST0, OST1, OST2, OST3, OST4, OST5
 495 File 4: OST6, OST7, OST0</screen>
 496           </para>
 497           <para>Here are several more sample round-robin stripe orders (each letter represents a
 498             different OST on a single OSS):</para>
 499           <informaltable frame="none">
 500             <tgroup cols="2">
 501               <colspec colname="c1" colwidth="50*"/>
 502               <colspec colname="c2" colwidth="50*"/>
 503               <tbody>
 504                 <row>
 505                   <entry>
 506                     <para> 3: AAA</para>
 507                   </entry>
 508                   <entry>
 509                     <para> One 3-OST OSS</para>
 510                   </entry>
 511                 </row>
 512                 <row>
 513                   <entry>
 514                     <para> 3x3: ABABAB</para>
 515                   </entry>
 516                   <entry>
 517                     <para> Two 3-OST OSSs</para>
 518                   </entry>
 519                 </row>
 520                 <row>
 521                   <entry>
 522                     <para> 3x4: BBABABA</para>
 523                   </entry>
 524                   <entry>
 525                     <para> One 3-OST OSS (A) and one 4-OST OSS (B)</para>
 526                   </entry>
 527                 </row>
 528                 <row>
 529                   <entry>
 530                     <para> 3x5: BBABBABA</para>
 531                   </entry>
 532                   <entry>
 533                     <para> One 3-OST OSS (A) and one 5-OST OSS (B)</para>
 534                   </entry>
 535                 </row>
 536                 <row>
 537                   <entry>
 538                     <para> 3x3x3: ABCABCABC</para>
 539                   </entry>
 540                   <entry>
 541                     <para> Three 3-OST OSSs</para>
 542                   </entry>
 543                 </row>
 544               </tbody>
 545             </tgroup>
 546           </informaltable>
 547         </listitem>
 548         <listitem>
 549           <para><emphasis role="bold">Weighted allocator</emphasis> - When the free space difference
 550             between the OSTs becomes significant, the weighting algorithm is used to influence OST
 551             ordering based on size (amount of free space available on each OST) and location
 552             (stripes evenly distributed across OSTs). The weighted allocator fills the emptier OSTs
 553             faster, but uses a weighted random algorithm, so the OST with the most free space is not
 554             necessarily chosen each time.</para>
 555         </listitem>
 556       </itemizedlist>
 557       <para>The allocation method is determined by the amount of free-space imbalance on the OSTs.
 558         When free space is relatively balanced across OSTs, the faster round-robin allocator is
 559         used, which maximizes network balancing. The weighted allocator is used when any two OSTs
 560         are out of balance by more than the specified threshold (17% by default). The threshold
 561         between the two allocation methods is defined in the file
 562             <literal>/proc/fs/<replaceable>fsname</replaceable>/lov/<replaceable>fsname</replaceable>-mdtlov/qos_threshold_rr</literal>. </para>
 563       <para>To set the <literal>qos_threshold_r</literal> to <literal>25</literal>,  enter this
 564         command on the
 565         MGS:<screen>lctl set_param lov.<replaceable>fsname</replaceable>-mdtlov.qos_threshold_rr=25</screen></para>
 566     </section>
 567     <section remap="h3">
 568       <title><indexterm>
 569           <primary>space</primary>
 570           <secondary>location weighting</secondary>
 571         </indexterm>Adjusting the Weighting Between Free Space and Location</title>
 572       <para>The weighting priority used by the weighted allocator is set in the file
 573             <literal>/proc/fs/<replaceable>fsname</replaceable>/lov/<replaceable>fsname</replaceable>-mdtlov/qos_prio_free</literal>.
 574         Increasing the value of <literal>qos_prio_free</literal> puts more weighting on the amount
 575         of free space available on each OST and less on how stripes are distributed across OSTs. The
 576         default value is <literal>91</literal> (percent). When the free space priority is set to
 577           <literal>100</literal> (percent), weighting is based entirely on free space and location
 578         is no longer used by the striping algorithm. </para>
 579       <para>To change the allocator weighting to <literal>100</literal>, enter this command on the
 580         MGS:</para>
 581       <screen>lctl conf_param <replaceable>fsname</replaceable>-MDT0000.lov.qos_prio_free=100</screen>
 582       <para> .</para>
 583       <note>
 584         <para>When <literal>qos_prio_free</literal> is set to <literal>100</literal>, a weighted
 585           random algorithm is still used to assign stripes, so, for example, if OST2 has twice as
 586           much free space as OST1, OST2 is twice as likely to be used, but it is not guaranteed to
 587           be used.</para>
 588       </note>
 589     </section>
 590   </section>
 591   <section xml:id="wide_striping">
 592     <title><indexterm>
 593         <primary>striping</primary>
 594         <secondary>wide striping</secondary>
 595       </indexterm><indexterm>
 596         <primary>wide striping</primary>
 597       </indexterm>Lustre Striping Internals</title>
 598     <para>Individual files can only be striped over a finite number of OSTs,
 599     based on the maximum size of the attributes that can be stored on the MDT.
 600     If the MDT is ldiskfs-based without the <literal>ea_inode</literal>
 601     feature, a file can be striped across at most 160 OSTs.  With ZFS-based
 602     MDTs, or if the <literal>ea_inode</literal> feature is enabled for an
 603     ldiskfs-based MDT, a file can be striped across up to 2000 OSTs.
 604     </para>
 605     <para>Lustre inodes use an extended attribute to record on which OST each
 606     object is located, and the identifier each object on that OST. The size of
 607     the extended attribute is a function of the number of stripes.</para>
 608     <para>If using an ldiskfs-based MDT, the maximum number of OSTs over which
 609     files can be striped can been raised to 2000 by enabling the
 610     <literal>ea_inode</literal> feature on the MDT:
 611     <screen>tune2fs -O ea_inode /dev/<replaceable>mdtdev</replaceable></screen>
 612     </para>
 613     <note><para>The maximum stripe count for a single file does not limit the
 614     maximum number of OSTs that are in the filesystem as a whole, only the
 615     maximum possible size and maximum aggregate bandwidth for the file.
 616     </para></note>
 617   </section>
 618 </chapter>