Whamcloud - gitweb
LUDOC-296 protocol: Reorganize the document ot be top-down
[doc/protocol.git] / lov_mds_md.txt
1 MDS Lock Value Block
2 ^^^^^^^^^^^^^^^^^^^^
3 [[struct-lov-mds-md]]
4
5 The 'lov_mds_md' structure is a Lock Value Block (LVB) for layout
6 locks. 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.
9
10 ----
11 struct lov_mds_md {
12         __u32 lmm_magic;
13         __u32 lmm_pattern;
14         struct ost_id   lmm_oi;
15         __u32 lmm_stripe_size;
16         __u16 lmm_stripe_count;
17         __u16 lmm_layout_gen;
18         struct lov_ost_data_v1 lmm_objects[0];
19 };
20 ----
21
22 The 'lmm_magic' field is filled in with the value LOV_MAGIC
23 (0x0BD10BD0) when the structure is in use. If the structure is in a
24 buffer of an RPC without the magic number in place, then the rest of
25 the structure is ignored.
26
27 The 'lmm_pattern' field is only ever set to LOV_PATTERN_RAID0
28 (0x001).
29
30 The 'lmm_oi' field gives the LOV object ID for the first OST of the
31 layout. This is the OST where striping will begin.
32
33 The 'lmm_stripe_size' field give the stripe size for the object. This
34 is how many bytes will be on a particular OST before going to the next
35 stripe.
36
37 The 'lmm_stripe_count' field gives how many OSTs the file is striped
38 over.
39
40 The 'lmm_layout_gen' field ges updated as the layout of the obeject is
41 updated. This way out-of-date references to the layout can be
42 recognized.
43
44 The 'lmm_objects' array gives per-stripe data for more complex
45 (non-uniform) layouts.
46
47