X-Git-Url: https://git.whamcloud.com/?a=blobdiff_plain;f=lov_mds_md.txt;h=97933cb098d6f1bf6947bc8c7eafd586996e4f47;hb=75ebff14a4d8714411bf755755b0823a2987dc44;hp=5d5f2f290215e02711f16e169f9fb099fa5bf066;hpb=f7539c5d000a6cce00dd20959e071892011561dc;p=doc%2Fprotocol.git diff --git a/lov_mds_md.txt b/lov_mds_md.txt index 5d5f2f2..97933cb 100644 --- a/lov_mds_md.txt +++ b/lov_mds_md.txt @@ -2,13 +2,16 @@ MDS Lock Value Block ^^^^^^^^^^^^^^^^^^^^ [[struct-lov-mds-md]] -The 'lov_mds_md' structure is a Lock Value Block (LVB) for layout -locks. In replies to lock requests and other situations requiring +The 'lov_mds_md' structure contains the layout of a single file. +In replies to lock requests and other situations requiring layout information from an MDT the 'lov_mds_md' information provides -details about the layout of a file across the OSTs. +details about the layout of a file across the OSTs. There may be +different types of layouts for different files, either 'lov_mds_md_v1' +or 'lov_mds_md_v3' as of Lustre 2.7, though they are very similar in +structure. ---- -struct lov_mds_md { +struct lov_mds_md_v1 { __u32 lmm_magic; __u32 lmm_pattern; struct ost_id lmm_oi; @@ -17,31 +20,77 @@ struct lov_mds_md { __u16 lmm_layout_gen; struct lov_ost_data_v1 lmm_objects[0]; }; + +struct lov_mds_md_v3 { + __u32 lmm_magic; + __u32 lmm_pattern; + struct ost_id lmm_oi; + __u32 lmm_stripe_size; + __u16 lmm_stripe_count; + __u16 lmm_layout_gen; + char lmm_pool_name[16]; + struct lov_ost_data_v1 lmm_objects[0]; +}; ---- -The 'lmm_magic' field is filled in with the value LOV_MAGIC -(0x0BD10BD0) when the structure is in use. If the structure is in a +The 'lmm_magic' field is filled in with the magic value that describes +the type of layout in use for a particular file. The rest of the layout +structure may vary depending on the magic value, but the 'lmm_magic' +value must be the first member of any valid file layout. The values +LOV_MAGIC_V1 (0x0BD10BD0) and LOV_MAGIC_V3 (0x0BD30BD0) are most +commonly used when the structure is in use. If the structure is in a buffer of an RPC without the magic number in place, then the rest of -the structure is ignored. +the structure is ignored. -The 'lmm_pattern' field is only ever set to LOV_PATTERN_RAID0 -(0x001). +The 'lmm_pattern' field describes the layout pattern within a particular +LOV_MAGIC layout type. Currently in Lustre 2.7 the most common pattern +is LOV_PATTERN_RAID0 (0x001). The high 16 bits of the 'lmm_pattern' field +may also contain flags that modify the layout. LOV_PATTERN_F_HOLE means +that there is a hole (missing object) within the layout, which is normally +caused by corruption or loss of the file layout that had to be rebuilt +by LFSCK. LOV_PATTERN_F_RELEASED is used by HSM to indicate that the +file data is not resident in the filesystem, but rather in an external +archive, so the layout is only a stub that describes the layout to use +when the file is restored. -The 'lmm_oi' field gives the LOV object ID for the first OST of the -layout. This is the OST where striping will begin. +The 'lmm_oi' field gives the identifier of the MDT object to which this +file belongs. See <> for more details. -The 'lmm_stripe_size' field give the stripe size for the object. This -is how many bytes will be on a particular OST before going to the next -stripe. +The 'lmm_stripe_size' field give the stripe size for the layout in bytes. +This is how many bytes will be on a particular OST object before going +to the next stripe. -The 'lmm_stripe_count' field gives how many OSTs the file is striped +The 'lmm_stripe_count' field gives how many OST objects the file is striped over. -The 'lmm_layout_gen' field ges updated as the layout of the obeject is -updated. This way out-of-date references to the layout can be -recognized. +The 'lmm_layout_gen' field is updated as the layout of the obeject is +updated. If the 'lmm_layout_gen' is modified, then clients can detect +the layout has changed when refreshing the layout after having lost the +layout lock. + +The 'lmm_pool_name' field is only in LOV_MAGIC_V3 layouts, and contains +the name of the OST pool used during the creation of the layout. + +For instantiated layouts, 'lmm_objects' array contains 'lmm_stripe_count' +'lov_ost_data_v1' structures with the per-stripe data for each OST object +in the layout. For uninstantiated layout templates, there will not be any +entries in the 'lmm_objects' array, which can be determined by the overall +layout size. + +---- +struct lov_ost_data_v1 { /* per-stripe data structure (little-endian)*/ + struct ost_id l_ost_oi; /* OST object ID */ + __u32 l_ost_gen; /* generation of this l_ost_idx */ + __u32 l_ost_idx; /* OST index in LOV (lov_tgt_desc->tgts) */ +}; +---- +[[struct-lov-ost-data-v1]] -The 'lmm_objects' array gives per-stripe data for more complex -(non-uniform) layouts. +The 'lov_ost_data_v1' structure is used for both LOV_MAGIC_V1 and +LOV_MAGIC_V3 types to describe the OST objects allocated to this +layout, one per object. +'l_ost_id' identifies the object on the OST specified by 'l_ost_idx'. +It may contain a OST object ID or a FID as described in <>. +The 'l_ost_gen' field is currently unused.