lov_mds_md.txt

   1 MDS Lock Value Block
   2 ^^^^^^^^^^^^^^^^^^^^
   3 [[struct-lov-mds-md]]
   4
   5 The 'lov_mds_md' structure contains the layout of a single file.
   6 In replies to lock requests and other situations requiring
   7 layout information from an MDT the 'lov_mds_md' information provides
   8 details about the layout of a file across the OSTs.  There may be
   9 different types of layouts for different files, either 'lov_mds_md_v1'
  10 or 'lov_mds_md_v3' as of Lustre 2.7, though they are very similar in
  11 structure.
  12
  13 ----
  14 struct lov_mds_md_v1 {
  15         __u32 lmm_magic;
  16         __u32 lmm_pattern;
  17         struct ost_id   lmm_oi;
  18         __u32 lmm_stripe_size;
  19         __u16 lmm_stripe_count;
  20         __u16 lmm_layout_gen;
  21         struct lov_ost_data_v1 lmm_objects[0];
  22 };
  23
  24 struct lov_mds_md_v3 {
  25         __u32 lmm_magic;
  26         __u32 lmm_pattern;
  27         struct ost_id   lmm_oi;
  28         __u32 lmm_stripe_size;
  29         __u16 lmm_stripe_count;
  30         __u16 lmm_layout_gen;
  31         char  lmm_pool_name[16];
  32         struct lov_ost_data_v1 lmm_objects[0];
  33 };
  34 ----
  35
  36 The 'lmm_magic' field is filled in with the magic value that describes
  37 the type of layout in use for a particular file.  The rest of the layout
  38 structure may vary depending on the magic value, but the 'lmm_magic'
  39 value must be the first member of any valid file layout.  The values
  40 LOV_MAGIC_V1 (0x0BD10BD0) and LOV_MAGIC_V3 (0x0BD30BD0) are most
  41 commonly used when the structure is in use. If the structure is in a
  42 buffer of an RPC without the magic number in place, then the rest of
  43 the structure is ignored.
  44
  45 The 'lmm_pattern' field describes the layout pattern within a particular
  46 LOV_MAGIC layout type.  Currently in Lustre 2.7 the most common pattern
  47 is LOV_PATTERN_RAID0 (0x001).  The high 16 bits of the 'lmm_pattern' field
  48 may also contain flags that modify the layout. LOV_PATTERN_F_HOLE means
  49 that there is a hole (missing object) within the layout, which is normally
  50 caused by corruption or loss of the file layout that had to be rebuilt
  51 by LFSCK.  LOV_PATTERN_F_RELEASED is used by HSM to indicate that the
  52 file data is not resident in the filesystem, but rather in an external
  53 archive, so the layout is only a stub that describes the layout to use
  54 when the file is restored.
  55
  56 The 'lmm_oi' field gives the identifier of the MDT object to which this
  57 file belongs.  See <<struct-ost-id>> for more details.
  58
  59 The 'lmm_stripe_size' field give the stripe size for the layout in bytes.
  60 This is how many bytes will be on a particular OST object before going
  61 to the next stripe.
  62
  63 The 'lmm_stripe_count' field gives how many OST objects the file is striped
  64 over.
  65
  66 The 'lmm_layout_gen' field is updated as the layout of the obeject is
  67 updated. If the 'lmm_layout_gen' is modified, then clients can detect
  68 the layout has changed when refreshing the layout after having lost the
  69 layout lock.
  70
  71 The 'lmm_pool_name' field is only in LOV_MAGIC_V3 layouts, and contains
  72 the name of the OST pool used during the creation of the layout.
  73
  74 For instantiated layouts, 'lmm_objects' array contains 'lmm_stripe_count'
  75 'lov_ost_data_v1' structures with the per-stripe data for each OST object
  76 in the layout.  For uninstantiated layout templates, there will not be any
  77 entries in the 'lmm_objects' array, which can be determined by the overall
  78 layout size.
  79
  80 ----
  81 struct lov_ost_data_v1 {          /* per-stripe data structure (little-endian)*/
  82         struct ost_id l_ost_oi;   /* OST object ID */
  83         __u32 l_ost_gen;          /* generation of this l_ost_idx */
  84         __u32 l_ost_idx;          /* OST index in LOV (lov_tgt_desc->tgts) */
  85 };
  86 ----
  87 [[struct-lov-ost-data-v1]]
  88
  89 The 'lov_ost_data_v1' structure is used for both LOV_MAGIC_V1 and
  90 LOV_MAGIC_V3 types to describe the OST objects allocated to this
  91 layout, one per object.
  92
  93 'l_ost_id' identifies the object on the OST specified by 'l_ost_idx'.
  94 It may contain a OST object ID or a FID as described in <<struct-ost-id>>.
  95 The 'l_ost_gen' field is currently unused.
  96