ManagingStripingFreeSpace.xml

   1 <?xml version='1.0' encoding='UTF-8'?>
   2 <!-- This document was created with Syntext Serna Free. --><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">
   3   <title xml:id="managingstripingfreespace.title">Managing File Striping and Free Space</title>
   4   <para>This chapter describes file striping and I/O options, and includes the following sections:</para>
   5   <itemizedlist>
   6     <listitem>
   7       <para><xref linkend="dbdoclet.50438209_79324"/></para>
   8     </listitem>
   9     <listitem>
  10       <para><xref linkend="dbdoclet.50438209_48033"/></para>
  11     </listitem>
  12     <listitem>
  13       <para><xref linkend="dbdoclet.50438209_78664"/></para>
  14     </listitem>
  15     <listitem>
  16       <para><xref linkend="dbdoclet.50438209_44776"/></para>
  17     </listitem>
  18     <listitem>
  19       <para><xref linkend="dbdoclet.50438209_10424"/></para>
  20     </listitem>
  21   </itemizedlist>
  22   <section xml:id="dbdoclet.50438209_79324">
  23       <title>
  24           <indexterm><primary>space</primary></indexterm>
  25           <indexterm><primary>striping</primary><secondary>how it works</secondary></indexterm>
  26           <indexterm><primary>striping</primary><see>space</see></indexterm>
  27           <indexterm><primary>space</primary><secondary>striping</secondary></indexterm>
  28   How Lustre Striping Works</title>
  29     <para>Lustre uses a round-robin algorithm for selecting the next OST to which a stripe is to be written. Normally the usage of OSTs is well balanced. However, if users create a small number of exceptionally large files or incorrectly specify striping parameters, imbalanced OST usage may result.</para>
  30     <para>The MDS allocates objects on sequential OSTs. Periodically, it will adjust the striping layout to eliminate some degenerated cases where applications that create very regular file layouts (striping patterns) would preferentially use a particular OST in the sequence.</para>
  31     <para>Stripes are written to sequential OSTs until free space across the OSTs differs by more than 20%. The MDS will then use weighted random allocations with a preference for allocating objects on OSTs with more free space. This can reduce I/O performance until space usage is rebalanced to within 20% again.</para>
  32     <para>For a more detailed description of stripe assignments, see <xref linkend="dbdoclet.50438209_10424"/>.</para>
  33   </section>
  34   <section xml:id="dbdoclet.50438209_48033">
  35       <title><indexterm><primary>striping</primary><secondary>considerations</secondary></indexterm>
  36           <indexterm><primary>space</primary><secondary>considerations</secondary></indexterm>
  37           Lustre File Striping Considerations</title>
  38     <para>Whether you should set up file striping and what parameter values you select depends on your need. A good rule of thumb is to stripe over as few objects as will meet those needs and no more.</para>
  39     <para>Some reasons for using striping include:</para>
  40     <itemizedlist>
  41       <listitem>
  42         <para><emphasis role="bold">Providing high-bandwidth access</emphasis>  - Many applications require high-bandwidth access to a single file - more bandwidth than can be provided by a single OSS. For example, scientific applications that write to a single file from hundreds of nodes, or a binary executable that is loaded by many nodes when an application starts.</para>
  43         <para>In cases like these, a file can be striped over as many OSSs as it takes to achieve the required peak aggregate bandwidth for that file. Striping across a larger number of OSSs should only be used when the file size is very large and/or is accessed by many nodes at a time. Currently, Lustre files can be striped across up to 2000 OSTs, the maximum stripe count for an ldiskfs file system.</para>
  44       </listitem>
  45       <listitem>
  46         <para><emphasis role="bold">Improving performance when OSS bandwidth is exceeded</emphasis>  - Striping across many OSSs can improve performance if the aggregate client bandwidth exceeds the server bandwidth and the application reads and writes data fast enough to take advantage of the additional OSS bandwidth. The largest useful stripe count is bounded by the I/O rate of the clients/jobs divided by the performance per OSS.</para>
  47       </listitem>
  48       <listitem>
  49         <para><emphasis role="bold">Providing space for very large files.</emphasis>  Striping is also useful when a single OST does not have enough free space to hold the entire file.</para>
  50       </listitem>
  51     </itemizedlist>
  52     <para>Some reasons to minimize or avoid striping:</para>
  53     <itemizedlist>
  54       <listitem>
  55         <para><emphasis role="bold">Increased overhead</emphasis>  - Striping results in more locks and extra network operations during common operations such as stat and unlink. Even when these operations are performed in parallel, one network operation takes less time than 100 operations.</para>
  56         <para>Increased overhead also results from server contention. Consider a cluster with 100 clients and 100 OSSs, each with one OST. If each file has exactly one object and the load is distributed evenly, there is no contention and the disks on each server can manage sequential I/O. If each file has 100 objects, then the clients all compete with one another for the attention of the servers, and the disks on each node seek in 100 different directions. In this case, there is needless contention.</para>
  57       </listitem>
  58       <listitem>
  59         <para><emphasis role="bold">Increased risk</emphasis>  - When a file is striped across all servers and one of the servers breaks down, a small part of each striped file is lost. By comparison, if each file has exactly one stripe, you lose fewer files, but you lose them in their entirety. Many users would prefer to lose some of their files entirely than all of their files partially.</para>
  60       </listitem>
  61     </itemizedlist>
  62     <section remap="h3">
  63         <title><indexterm><primary>striping</primary><secondary>size</secondary></indexterm>
  64             Choosing a Stripe Size</title>
  65       <para>Choosing a stripe size is a small balancing act, but there are reasonable defaults.</para>
  66       <itemizedlist>
  67         <listitem>
  68           <para><emphasis role="bold">The stripe size must be a multiple of the page size.</emphasis>  Lustre&apos;s tools enforce a multiple of 64 KB (the maximum page size on ia64 and PPC64 nodes) so that users on platforms with smaller pages do not accidentally create files that might cause problems for ia64 clients.</para>
  69         </listitem>
  70         <listitem>
  71           <para><emphasis role="bold">The smallest recommended stripe size is 512 KB.</emphasis>  Although you can create files with a stripe size of 64 KB, the smallest practical stripe size is 512 KB because Lustre sends 1MB chunks over the network. Choosing a smaller stripe size may result in inefficient I/O to the disks and reduced performance.</para>
  72         </listitem>
  73         <listitem>
  74           <para><emphasis role="bold">A good stripe size for sequential I/O using high-speed networks is between 1 MB and 4 MB.</emphasis>  In most situations, stripe sizes larger than 4 MB may result in longer lock hold times and contention on shared file access.</para>
  75         </listitem>
  76         <listitem>
  77           <para><emphasis role="bold">The maximum stripe size is 4GB.</emphasis>  Using a large stripe size can improve performance when accessing very large files. It allows each client to have exclusive access to its own part of a file. However, it can be counterproductive in some cases if it does not match your I/O pattern.</para>
  78         </listitem>
  79         <listitem>
  80           <para><emphasis role="bold">Choose a stripe pattern that takes into account your application&apos;s write patterns.</emphasis>  Writes that cross an object boundary are slightly less efficient than writes that go entirely to one server. If the file is written in a very consistent and aligned way, make the stripe size a multiple of the write() size.</para>
  81         </listitem>
  82         <listitem>
  83           <para><emphasis role="bold">The choice of stripe size has no effect on a single-stripe file.</emphasis></para>
  84         </listitem>
  85       </itemizedlist>
  86     </section>
  87   </section>
  88   <section xml:id="dbdoclet.50438209_78664">
  89       <title><indexterm><primary>striping</primary><secondary>configuration</secondary></indexterm>
  90           Setting the File Layout/Striping Configuration (<literal>lfs setstripe</literal>)</title>
  91     <para>Use the <literal>lfs setstripe</literal> command to create new files with a specific file layout (stripe pattern) configuration.</para>
  92     <screen>lfs setstripe [--size|-s stripe_size] [--count|-c stripe_count]
  93 [--index|-i start_ost] [--pool|-p pool_name] &lt;filename|dirname&gt; </screen>
  94     <para><emphasis role="bold">
  95         <literal>stripe_size</literal>
  96       </emphasis>
  97       </para>
  98     <para>The <literal>stripe_size</literal> indicates how much data to write to one OST before moving to the next OST. The default <literal>stripe_size</literal> is 1 MB, and passing a stripe_size of 0 causes the default stripe size to be used. Otherwise, the <literal>stripe_size</literal> value must be a multiple of 64 KB.</para>
  99     <para><emphasis role="bold">
 100         <literal>stripe_count</literal>
 101       </emphasis>
 102       </para>
 103     <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>
 104     <para><emphasis role="bold">
 105         <literal>start_ost</literal>
 106       </emphasis>
 107       </para>
 108     <para>The start OST is the first OST to which files are written. The default value for <literal>start_ost</literal> is -1, which allows the MDS to choose the starting index. This setting is strongly recommended, as it allows space and load balancing to be done by the MDS as needed. Otherwise, the file starts on the specified OST index. The numbering of the OSTs starts at 0.</para>
 109     <note>
 110       <para>If you pass a <literal>start_ost</literal> value of 0 and a <literal>stripe_count</literal> value of <emphasis>1</emphasis>, all files are written to OST 0, until space is exhausted. This is probably not what you meant to do. If you only want to adjust the stripe count and keep the other parameters at their default settings, do not specify any of the other parameters:</para>
 111       <para><screen>lfs setstripe -c &lt;stripe_count&gt; &lt;file&gt;</screen></para>
 112     </note>
 113     <para><emphasis role="bold">
 114         <literal>pool_name</literal>
 115       </emphasis>
 116       </para>
 117     <para>Specify the OST pool on which the file will be written. This allows limiting the OSTs used to a subset of all OSTs in the file system. For more details about using OST pools, see <link xl:href="ManagingFileSystemIO.html#50438211_75549">Creating and Managing OST Pools</link>.</para>
 118     <section remap="h3">
 119       <title>Using a Specific Striping Pattern/File Layout for a Single File</title>
 120       <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>
 121       <section xml:id="dbdoclet.50438209_60155">
 122         <title>Setting the Stripe Size</title>
 123         <para>The command to create a new file with a specified stripe size is similar to:</para>
 124         <screen>[client]# lfs setstripe -s 4M /mnt/lustre/new_file</screen>
 125         <para>This example command creates the new file <literal>/mnt/lustre/new_file</literal> with a stripe size of 4 MB.</para>
 126         <para>Now, when a file is created, the new stripe setting evenly distributes the data over all the available OSTs:</para>
 127         <screen> [client]# lfs getstripe /mnt/lustre/new_file
 128 /mnt/lustre/4mb_file
 129 lmm_stripe_count:   1
 130 lmm_stripe_size:    4194304
 131 lmm_stripe_offset:  1
 132 obdidx     objid                   objid                           group
 133 1  690550                  0xa8976                         0 </screen>
 134         <para>As can be seen, the stripe size is 4 MB.</para>
 135       </section>
 136       <section remap="h4">
 137           <title><indexterm><primary>striping</primary><secondary>count</secondary></indexterm>
 138               Setting the Stripe Count</title>
 139         <para>The command below creates a new file with a stripe count of -1 to specify striping over all available OSTs:</para>
 140         <screen>[client]# lfs setstripe -c -1 /mnt/lustre/full_stripe</screen>
 141         <para>The example below indicates that the file full_stripe is striped over all six active OSTs in the configuration:</para>
 142         <screen>[client]# lfs getstripe /mnt/lustre/full_stripe
 143 /mnt/lustre/full_stripe
 144 obdidx objid objid group
 145 0  8       0x8             0
 146 1  4       0x4             0
 147 2  5       0x5             0
 148 3  5       0x5             0
 149 4  4       0x4             0
 150 5  2       0x2             0</screen>
 151         <para> This is in contrast to the output in <xref linkend="dbdoclet.50438209_60155"/> that shows only a single object for the file.</para>
 152       </section>
 153     </section>
 154     <section remap="h3">
 155       <title><indexterm><primary>striping</primary><secondary>per directory</secondary></indexterm>Changing Striping for a Directory</title>
 156       <para>In a directory, the <literal>lfs setstripe</literal> command sets a default striping configuration for files created in the directory. The usage is the same as <literal>lfs setstripe</literal> for a regular file, except that the directory must exist prior to setting the default striping configuration. If a file is created in a directory with a default stripe configuration (without otherwise specifying striping), Lustre uses those striping parameters instead of the file system default for the new file.</para>
 157       <para>To change the striping pattern (file layout) for a sub-directory, create a directory with desired file layout as described above. Sub-directories inherit the file layout of the root/parent directory.</para>
 158     </section>
 159     <section remap="h3">
 160       <title><indexterm><primary>striping</primary><secondary>per file system</secondary></indexterm>Changing Striping for a File System</title>
 161       <para>Change the striping on the file system root will change the striping for all newly created files that would otherwise have a striping parameter from the parent directory or explicitly on the command line.</para>
 162       <note>
 163         <para>Striping of new files and sub-directories is done per the striping parameter settings of the root directory. Once you set striping on the root directory, then, by default, it applies to any new child directories created in that root directory (unless they have their own striping settings).</para>
 164       </note>
 165     </section>
 166     <section remap="h3">
 167       <title><indexterm><primary>striping</primary><secondary>on specific OST</secondary></indexterm>Creating a File on a Specific OST</title>
 168       <para>You can use <literal>lfs setstripe</literal> to create a file on a specific OST. In the following example, the file &quot;<literal>bob</literal>&quot; will be created on the first OST (id 0).</para>
 169       <screen>$ lfs setstripe --count 1 --index 0 bob
 170 $ dd if=/dev/zero of=bob count=1 bs=100M
 171 1+0 records in
 172 1+0 records out
 173 $ lfs getstripe bob</screen>
 174       <para>OBDS:</para>
 175       <screen>0: home-OST0000_UUID ACTIVE
 176 [...]
 177 bob
 178    obdidx          objid                   objid                   group
 179    0               33459243                0x1fe8c2b               0</screen>
 180     </section>
 181   </section>
 182   <section xml:id="dbdoclet.50438209_44776">
 183     <title><indexterm><primary>striping</primary><secondary>getting information</secondary></indexterm>Retrieving File Layout/Striping Information (<literal>getstripe</literal>)</title>
 184     <para>The <literal>lfs getstripe</literal> command is used to display information that shows over which OSTs a file is distributed. For each OST, the index and UUID is displayed, along with the OST index and object ID for each stripe in the file. For directories, the default settings for files created in that directory are printed.</para>
 185     <section remap="h3">
 186       <title>Displaying the Current Stripe Size</title>
 187       <para>To see the current stripe size, use the <literal>lfs getstripe</literal> command on a Lustre file or directory. For example:</para>
 188       <screen>[client]# lfs getstripe /mnt/lustre </screen>
 189       <para>This command produces output similar to this:</para>
 190       <screen>/mnt/lustre
 191 (Default) stripe_count: 1 stripe_size: 1M stripe_offset: -1</screen>
 192       <para>In this example, the default stripe count is 1 (data blocks are striped over a single OSTs), the default stripe size is 1 MB, and objects are created over all available OSTs.</para>
 193     </section>
 194     <section remap="h3">
 195       <title>Inspecting the File Tree</title>
 196       <para>To inspect an entire tree of files, use the <literal>lfs</literal> find command:</para>
 197       <screen>lfs find [--recursive | -r] &lt;file or directory&gt; ...</screen>
 198       <para>You can also use <literal>ls -l /proc/<replaceable>&lt;pid&gt;</replaceable>/fd/</literal> to find open files using Lustre. For example:</para>
 199       <screen>$ lfs getstripe $(readlink /proc/$(pidof cat)/fd/1)</screen>
 200       <para>Typical output is:</para>
 201       <screen>/mnt/lustre/foo
 202 obdidx                     objid                   objid                   \
 203 group
 204 2                  835487                  0xcbf9f                 0</screen>
 205       <para>In this example, the file lives on <literal>obdidx</literal><literal> 2</literal>, which is <literal>lustre-OST0002</literal>. To see which node is serving that OST, run:</para>
 206       <screen>$ lctl get_param osc.lustre-OST0002-osc.ost_conn_uuid</screen>
 207       <para>Typical output is:</para>
 208       <screen>osc.lustre-OST0002-osc.ost_conn_uuid=192.168.20.1@tcp</screen>
 209     </section>
 210   </section>
 211   <section xml:id="dbdoclet.50438209_10424">
 212     <title><indexterm><primary>space</primary><secondary>free space</secondary></indexterm>Managing Free Space</title>
 213     <para>The MDT assigns file stripes to OSTs based on location (which OSS) and size considerations (free space) to optimize file system performance. Emptier OSTs are preferentially selected for stripes, and stripes are preferentially spread out between OSSs to increase network bandwidth utilization. The weighting factor between these two optimizations can be adjusted by the user.</para>
 214     <section xml:id="dbdoclet.50438209_35838">
 215       <title>Checking File System Free Space</title>
 216       <para>Free space is an important consideration in assigning file stripes. The <literal>lfs df</literal> command shows available disk space on the mounted Lustre file system and space consumption per OST. If multiple Lustre file systems are mounted, a path may be specified, but is not required.</para>
 217       <informaltable frame="all">
 218         <tgroup cols="2">
 219           <colspec colname="c1" colwidth="50*"/>
 220           <colspec colname="c2" colwidth="50*"/>
 221           <thead>
 222             <row>
 223               <entry>
 224                 <para><emphasis role="bold">Option</emphasis></para>
 225               </entry>
 226               <entry>
 227                 <para><emphasis role="bold">Description</emphasis></para>
 228               </entry>
 229             </row>
 230           </thead>
 231           <tbody>
 232             <row>
 233               <entry>
 234                 <para> <literal>-h</literal></para>
 235               </entry>
 236               <entry>
 237                 <para> Human-readable print sizes in human readable format (for example: 1K, 234M, 5G).</para>
 238               </entry>
 239             </row>
 240             <row>
 241               <entry>
 242                 <para> <literal role="bold">-i, --inodes</literal></para>
 243               </entry>
 244               <entry>
 245                 <para> Lists inodes instead of block usage.</para>
 246               </entry>
 247             </row>
 248           </tbody>
 249         </tgroup>
 250       </informaltable>
 251       <note>
 252         <para>The <literal>df -i</literal> and <literal>lfs df -i</literal> commands show the minimum number of inodes that can be created in the file system. Depending on the configuration, it may be possible to create more inodes than initially reported by <literal>df -i</literal>. Later, <literal>df -i</literal> operations will show the current, estimated free inode count.</para>
 253         <para>If the underlying file system has fewer free blocks than inodes, then the total inode count for the file system reports only as many inodes as there are free blocks. This is done because Lustre may need to store an external attribute for each new inode, and it is better to report a free inode count that is the guaranteed, minimum number of inodes that can be created.</para>
 254       </note>
 255       <para><emphasis role="bold">Examples</emphasis></para>
 256       <screen>[lin-cli1] $ lfs df
 257 UUID                       1K-blockS               Used                    \
 258 Available               Use%            Mounted on
 259 mds-lustre-0_UUID  9174328                 1020024                 8154304 \
 260                 11%             /mnt/lustre[MDT:0]
 261 ost-lustre-0_UUID  94181368                56330708                37850660\
 262                 59%             /mnt/lustre[OST:0]
 263 ost-lustre-1_UUID  94181368                56385748                37795620\
 264                 59%             /mnt/lustre[OST:1]
 265 ost-lustre-2_UUID  94181368                54352012                39829356\
 266                 57%             /mnt/lustre[OST:2]
 267 filesystem summary:        282544104               167068468               \
 268 39829356                57%             /mnt/lustre
 269
 270 [lin-cli1] $ lfs df -h
 271 UUID                       bytes                   Used                    \
 272 Available               Use%            Mounted on
 273 mds-lustre-0_UUID  8.7G                    996.1M                  7.8G    \
 274                 11%             /mnt/lustre[MDT:0]
 275 ost-lustre-0_UUID  89.8G                   53.7G                   36.1G   \
 276                 59%             /mnt/lustre[OST:0]
 277 ost-lustre-1_UUID  89.8G                   53.8G                   36.0G   \
 278                 59%             /mnt/lustre[OST:1]
 279 ost-lustre-2_UUID  89.8G                   51.8G                   38.0G   \
 280                 57%             /mnt/lustre[OST:2]
 281 filesystem summary:        269.5G                  159.3G                  \
 282 110.1G                  59%             /mnt/lustre
 283
 284 [lin-cli1] $ lfs df -i
 285 UUID                       Inodes                  IUsed                   \
 286 IFree                   IUse%           Mounted on
 287 mds-lustre-0_UUID  2211572                 41924                   2169648 \
 288                 1%              /mnt/lustre[MDT:0]
 289 ost-lustre-0_UUID  737280                  12183                   725097  \
 290                 1%              /mnt/lustre[OST:0]
 291 ost-lustre-1_UUID  737280                  12232                   725048  \
 292                 1%              /mnt/lustre[OST:1]
 293 ost-lustre-2_UUID  737280                  12214                   725066  \
 294                 1%              /mnt/lustre[OST:2]
 295 filesystem summary:        2211572                 41924                   \
 296 2169648                 1%              /mnt/lustre[OST:2]</screen>
 297     </section>
 298     <section remap="h3">
 299         <title><indexterm><primary>striping</primary><secondary>allocations</secondary></indexterm>
 300             Using Stripe Allocations</title>
 301       <para>Two stripe allocation methods are provided: <emphasis>round-robin</emphasis> and <emphasis>weighted</emphasis>. By default, the allocation method is determined by the amount of free-space imbalance on the OSTs. The weighted allocator is used when any two OSTs are imbalanced by more than 20%. Otherwise, the faster round-robin allocator is used. (The round-robin order maximizes network balancing.)</para>
 302       <itemizedlist>
 303         <listitem>
 304           <para><emphasis role="bold">Round-robin allocator</emphasis> - When OSTs have approximately the same amount of free space (within 20%), an efficient round-robin allocator is used. The round-robin allocator alternates stripes between OSTs on different OSSs, so the OST used for stripe 0 of each file is evenly distributed among OSTs, regardless of the stripe count. Here are several sample round-robin stripe orders (each letter represents a different OST on a single OSS):</para>
 305           <informaltable frame="none">
 306             <tgroup cols="2">
 307               <colspec colname="c1" colwidth="50*"/>
 308               <colspec colname="c2" colwidth="50*"/>
 309               <tbody>
 310                 <row>
 311                   <entry>
 312                     <para> 3: AAA</para>
 313                   </entry>
 314                   <entry>
 315                     <para> One 3-OST OSS</para>
 316                   </entry>
 317                 </row>
 318                 <row>
 319                   <entry>
 320                     <para> 3x3: ABABAB</para>
 321                   </entry>
 322                   <entry>
 323                     <para> Two 3-OST OSSs</para>
 324                   </entry>
 325                 </row>
 326                 <row>
 327                   <entry>
 328                     <para> 3x4: BBABABA</para>
 329                   </entry>
 330                   <entry>
 331                     <para> One 3-OST OSS (A) and one 4-OST OSS (B)</para>
 332                   </entry>
 333                 </row>
 334                 <row>
 335                   <entry>
 336                     <para> 3x5: BBABBABA</para>
 337                   </entry>
 338                   <entry>
 339                     <para> One 3-OST OSS (A) and one 5-OST OSS (B)</para>
 340                   </entry>
 341                 </row>
 342                 <row>
 343                   <entry>
 344                     <para> 3x3x3: ABCABCABC</para>
 345                   </entry>
 346                   <entry>
 347                     <para> Three 3-OST OSSs</para>
 348                   </entry>
 349                 </row>
 350               </tbody>
 351             </tgroup>
 352           </informaltable>
 353         </listitem>
 354         <listitem>
 355           <para><emphasis role="bold">Weighted allocator</emphasis>  - When the free space difference between the OSTs is significant (by default, 20% of the free space), then a weighting algorithm is used to influence OST ordering based on size and location. Note that these are weightings for a random algorithm, so the OST with the most free space is not necessarily chosen each time. On average, the weighted allocator fills the emptier OSTs faster.</para>
 356         </listitem>
 357       </itemizedlist>
 358     </section>
 359     <section remap="h3">
 360         <title><indexterm><primary>space</primary><secondary>location weighting</secondary></indexterm>>Adjusting the Weighting Between Free Space and Location</title>
 361       <para>The weighting priority can be adjusted in the <literal>/proc</literal> file <literal>/proc/fs/lustre/lov/lustre-mdtlov/qos_prio_free proc</literal>. The default value is 90%. Use this command on the MGS to permanently change this weighting:</para>
 362       <screen>lctl conf_param &lt;fsname&gt;-MDT0000.lov.qos_prio_free=90</screen>
 363       <para>Increasing this value puts more weighting on free space. When the free space priority is set to 100%, then location is no longer used in stripe-ordering calculations and weighting is based entirely on free space.</para>
 364       <note>
 365         <para>Setting the priority to 100% means that OSS distribution does not count in the weighting, but the stripe assignment is still done via a weighting. For example, if OST2 has twice as much free space as OST1, then OST2 is twice as likely to be used, but it is not guaranteed to be used.</para>
 366       </note>
 367     </section>
 368   </section>
 369 </chapter>