WARNING: This is the _old_ Lustre wiki, and it is in the process of being retired. The information found here is all likely to be out of date. Please search the new wiki for more up to date information.

Difference between revisions of "Architecture - Pools of targets"

From Obsolete Lustre Wiki
Jump to navigationJump to search
m (Protected "Architecture - Pools of targets" ([edit=sysop] (indefinite) [move=sysop] (indefinite)))
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
'''''Note:''''' The content on this page reflects the state of design of a Lustre feature at a particular point in time and may contain outdated information.  
+
'''''Note:''''' ''The content on this page reflects the state of design of a Lustre feature at a particular point in time and may contain outdated information.''
  
 
== Definitions ==
 
== Definitions ==
Line 44: Line 44:
 
If an extended attribute is encountered that contains a pool name the MDS routines using that attribute access the hash table and allocate objects accordingly.
 
If an extended attribute is encountered that contains a pool name the MDS routines using that attribute access the hash table and allocate objects accordingly.
  
Command line utilities will start to use the libarg2 library.  An additional CFS library will be added to allow comma separated sequences, ranges, kilo/mega/giga/tera/peta/exa/yotta bytes to be understood and other argument parsing issues.
+
Command line utilities will start to use the libarg2 library.  An additional library will be added to allow comma separated sequences, ranges, kilo/mega/giga/tera/peta/exa/yotta bytes to be understood and other argument parsing issues.

Latest revision as of 19:48, 2 February 2010

Note: The content on this page reflects the state of design of a Lustre feature at a particular point in time and may contain outdated information.

Definitions

Definition: A pool is a name associated with a set of OSTs in a Lustre cluster.

Note the following:

  1. An OST can be in multiple pools
  2. No ordering is implied or defined
  3. Memberhship of a pool can change over time

The purpose of pools is to make object placement definitions more flexible.

Use cases

  1. A directory or file can be given an EA restricting striping to a pool
    1. Wide Striping can use this to stripe over a large number of OSTs
    2. a subset of OSTs may be slower or faster than others and preferred for certain jobs
    3. doing Object Migration from a set OSTs to another pool of OSTs
  2. Pools can be assigned to specific clusters by client NID perferably or exclusively
  3. Pools can be assigned to specific users or groups by UID/GID preferably or exclusively
  4. Pools can be assigned to specific types of files by filename (e.g. *.mpg) to allow different striping for some files without requiring a default EA for all files in the output directory

Command line Definitions

Pools can be defined using configuration log entries of the following type:

  1. lctl pool_new <fs name>.<pool name> Define a new pool, where pool name is an ascii string of up to 16 characters
  2. lctl pool_add <fs name>.<pool name> <ostname index list1> ... Add the named OSTs to the pool. Each addition leads to a new llog configuration record, but for convenience a single command can be given. <ostname index list> is <fs name>-OST<list> where <list> = N,<list> or <first[-last[/step]]>,<list>. if leading <fsname> or ending _UUID are missing, they are automatically added.
  3. lctl pool_remove <fs name>.<pool name> <ostname index list1> ... Remove the named OST from the pool
  4. lctl pool_destroy <fs name>.<pool name> Remove the definition of the pool

To set striping patterns:

lfs setstripe [--size|-s stripe_size] [--index|-i stripe_index]
              [--count|-c stripe_count] [--pool|-p pool_name]
              [--raid|-r raid_pattern] {file|dir}

To see already defined pools:

lfs poollist <fsname>[.<poolname>] | <absolute pathname>

Implementation Constraints

When the configuration llog is parsed nodes that require the pool information the node will build a hash table mapping pool names to lists of OST's.

If an extended attribute is encountered that contains a pool name the MDS routines using that attribute access the hash table and allocate objects accordingly.

Command line utilities will start to use the libarg2 library. An additional library will be added to allow comma separated sequences, ranges, kilo/mega/giga/tera/peta/exa/yotta bytes to be understood and other argument parsing issues.