1md.tab(4)                        File Formats                        md.tab(4)
2
3
4

NAME

6       md.tab, md.cf - Solaris Volume Manager utility files
7

SYNOPSIS

9       /etc/lvm/md.tab
10       /etc/lvm/md.cf
11
12

DESCRIPTION

14       The  file /etc/lvm/md.tab can be used by metainit(1M) and metadb(1M) to
15       configure metadevices, hot spare pools, and metadevice  state  database
16       replicas  in  a  batch-like mode. Solaris Volume Manager does not store
17       configuration information in the /etc/lvm/md.tab file. You can use:
18
19         metastat -p > /etc/lvm/md.tab
20
21
22
23
24       to create this file. Edit it by hand  using  the  instructions  in  the
25       md.tab.4  file.  Similarly,  if  no hot spares are in use, the cp md.cf
26       md.tab command generates an acceptable version of the md.tab file, with
27       the editing caveats previously mentioned.
28
29
30       When  using  the md.tab file, each metadevice, hot spare pool, or state
31       database replica in the file must have  a  unique  entry.  Entries  can
32       include the following: simple metadevices (stripes, concatenations, and
33       concatenations of stripes); mirrors, soft partitions, and RAID5 metade‐
34       vices;  hot  spare  pools;  and state database replicas. Because md.tab
35       contains only entries that you enter in it, do not rely on the file for
36       the current configuration of metadevices, hot spare pools, and replicas
37       on the system at any given time.
38
39
40       Tabs, spaces, comments (by using a pound sign, #), and continuation  of
41       lines (by using a backslash-newline), are allowed.
42
43
44       Typically, you set up metadevices according to information specified on
45       the command line by using the metainit command. Likewise,  you  set  up
46       state database replicas with the metadb command.
47
48
49       An  alternative  to the command line is to use the md.tab file. Metade‐
50       vices and state database replicas can be specified in the  md.tab  file
51       in any order, and then activated in a batch-like mode with the metainit
52       and metadb commands.
53
54
55       If you edit the md.tab file, you  specify  one  complete  configuration
56       entry  per  line.  Metadevices  are  defined  using  the same syntax as
57       required by the metainit command. You then  run  the  metainit  command
58       with  either  the  -a option, to activate all metadevices in the md.tab
59       file, or with the metadevice name corresponding to a specific  configu‐
60       ration entry.
61
62
63       metainit  does  not  maintain  the state of the volumes that would have
64       been created when metainit is run with both the -a and -n flags.  If  a
65       device  d0 is created in the first line of the md.tab file, and a later
66       line in md.tab assumes the existence of d0, the later  line  will  fail
67       when metainit -an runs (even if it would succeed with metainit -a).
68
69
70       State database replicas are defined in the /etc/lvm/md.tab file as fol‐
71       lows: mddb number options [ slice... ] Where mddb number is the charac‐
72       ters  mddb  followed  by a number of two or more digits that identifies
73       the state database replica. slice is a  physical  slice.  For  example:
74       mddb05  /dev/dsk/c0t1d0s2.  The  file /etc/lvm/md.cf is a backup of the
75       configuration used for disaster recovery. Whenever the  Volume  Manager
76       configuration  is  changed,  this file is automatically updated (except
77       when hot sparing occurs). You should not directly edit this file.
78

EXAMPLES

80       Example 1 Concatenation
81
82
83       All drives in the following examples have the same size of 525 Mbytes.
84
85
86
87       This example shows a metadevice, /dev/md/dsk/d7, consisting of  a  con‐
88       catenation of four disks.
89
90
91         #
92         # (concatenation of four disks)
93         #
94         d7 4 1 c0t1d0s0 1 c0t2d0s0 1 c0t3d0s0 1 c0t4d0s0
95
96
97
98       The  number  4  indicates there are four individual stripes in the con‐
99       catenation. Each stripe is made  of  one  slice,  hence  the  number  1
100       appears  in front of each slice. Note that the first disk sector in all
101       of the above devices contains a disk label. To preserve the  labels  on
102       devices  /dev/dsk/c0t2d0s0,  /dev/dsk/c0t3d0s0,  and /dev/dsk/c0t4d0s0,
103       the metadisk driver must skip at least the first sector of those  disks
104       when  mapping accesses across the concatenation boundaries. Since skip‐
105       ping only the first sector would create an irregular disk geometry, the
106       entire  first  cylinder  of  these  disks  will be skipped. This allows
107       higher level file system software to optimize  block  allocations  cor‐
108       rectly.
109
110
111       Example 2 Stripe
112
113
114       This  example  shows  a  metadevice, /dev/md/dsk/d15, consisting of two
115       slices.
116
117
118         #
119         # (stripe consisting of two disks)
120         #
121         d15 1 2 c0t1d0s2 c0t2d0s2 -i 32k
122
123
124
125       The number 1 indicates that one stripe is being  created.  Because  the
126       stripe  is  made of two slices, the number 2 follows next. The optional
127       -i followed by 32k specifies the interlace size will be 32  Kbytes.  If
128       the interlace size were not specified, the stripe would use the default
129       value of 16 Kbytes.
130
131
132       Example 3 Concatenation of Stripes
133
134
135       This example shows a metadevice, /dev/md/dsk/d75, consisting of a  con‐
136       catenation of two stripes of three disks.
137
138
139         #
140         # (concatenation of two stripes, each consisting of three disks)
141         #
142         d75 2 3 c0t1d0s2 c0t2d0s2 c0t3d0s2 -i 16k \
143               3 c1t1d0s2 c1t2d0s2 c1t3d0s2 -i 32k
144
145
146
147       On  the  first line, the -i followed by 16k specifies that the stripe's
148       interlace size is 16 Kbytes. The second set specifies the stripe inter‐
149       lace  size  will  be  32  Kbytes.  If the second set did not specify 32
150       Kbytes, the set would use default interlace value  of  16  Kbytes.  The
151       blocks of each set of three disks are interlaced across three disks.
152
153
154       Example 4 Mirroring
155
156
157       This  example  shows a three-way mirror, /dev/md/dsk/d50, consisting of
158       three submirrors. This mirror does not contain any existing data.
159
160
161         #
162         # (mirror)
163         #
164         d50 -m d51
165         d51 1 1 c0t1d0s2
166         d52 1 1 c0t2d0s2
167         d53 1 1 c0t3d0s2
168
169
170
171       In this example, a one-way mirror is first defined using the -m option.
172       The one-way mirror consists of submirror d51. The other two submirrors,
173       d52 and d53, are  attached  later  using  the  metattach  command.  The
174       default  read  and write options in this example are a round-robin read
175       algorithm and parallel writes to all submirrors.  The  order  in  which
176       mirrors appear in the /etc/lvm/md.tab file is unimportant.
177
178
179       Example 5 RAID5
180
181
182       This example shows a RAID5 metadevice, d80, consisting of three slices:
183
184
185         #
186         # (RAID devices)
187         #
188         d80 -r c0t1d0s1 c1t0d0s1 c2t0d0s1 -i 20k
189
190
191
192       In this example, a RAID5 metadevice is defined using the -r option with
193       an interlace size of 20 Kbytes. The data and parity  segments  will  be
194       striped across the slices, c0t1d0s1, c1t0d0s1, and c2t0d0s1.
195
196
197       Example 6 Soft Partition
198
199
200       This example shows a soft partition, d85, that reformats an entire 9 GB
201       disk. Slice 0 occupies all of the disk except for the few Mbytes  taken
202       by slice 7, which is space reserved for a state database replica. Slice
203       7 will be a minimum of 4Mbytes, but could be larger, depending  on  the
204       disk geometry. d85 sits on c3t4d0s0.
205
206
207
208       Drives are repartitioned when they are added to a diskset only if Slice
209       7 is not set up correctly. A small portion of each drive is reserved in
210       Slice  7  for use by Volume Manager. The remainder of the space on each
211       drive is placed into Slice 0. Any existing data on the  disks  is  lost
212       after repartitioning. After adding a drive to a diskset, you can repar‐
213       tition the drive as necessary. However, Slice 7 should  not  be  moved,
214       removed, or overlapped with any other partition.
215
216
217
218       Manually  specifying  the offsets and extents of soft partitions is not
219       recommended. This example is included for to provide  a  better  under‐
220       standing of the file if it is automatically generated and for complete‐
221       ness.
222
223
224         #
225         # (Soft Partitions)
226         d85 -p -e c3t4d0 9g
227
228
229
230       In this example, creating the soft partition and required space for the
231       state database replica occupies all 9 GB of disk c3t4d0.
232
233
234       Example 7 Soft Partition
235
236
237       This  example shows the command used to re-create a soft partition with
238       two extents, the first one starting at offset 20483 and  extending  for
239       20480 blocks and the second extent starting at 135398 and extending for
240       20480 blocks:
241
242
243         #
244         # (Soft Partitions)
245         #
246         d1 -p c0t3d0s0 -o 20483 -b 20480 -o 135398 -b 20480
247
248
249       Example 8 Hot Spare
250
251
252       This example shows a three-way mirror, /dev/md/dsk/d10,  consisting  of
253       three submirrors and three hot spare pools.
254
255
256         #
257         # (mirror and hot spare)
258         #
259         d10 -m d20
260         d20 1 1 c1t0d0s2 -h hsp001
261         d30 1 1 c2t0d0s2 -h hsp002
262         d40 1 1 c3t0d0s2 -h hsp003
263         hsp001 c2t2d0s2 c3t2d0s2 c1t2d0s2
264         hsp002 c3t2d0s2 c1t2d0s2 c2t2d0s2
265         hsp003 c1t2d0s2 c2t2d0s2 c3t2d0s2
266
267
268
269       In this example, a one-way mirror is first defined using the -m option.
270       The submirrors are attached later using the metattach(1M) command.  The
271       hot  spare  pools  to  be  used  are tied to the submirrors with the -h
272       option. In this example, there are three  disks  used  as  hot  spares,
273       defined  in  three  separate  hot  spare pools. The hot spare pools are
274       given the names hsp001, hsp002, and hsp003. Setting up three hot  spare
275       pools  rather  than  assigning  just  one hot spare with each component
276       helps to maximize the use of hardware. This configuration  enables  the
277       user  to  specify  that the most desirable hot spare be selected first,
278       and improves availability by having more hot spares available.  At  the
279       end  of  the  entry,  the hot spares to be used are defined. Note that,
280       when using the md.tab file, to associate hot spares  with  metadevices,
281       the  hot  spare  spool does not have to exist prior to the association.
282       Volume Manager takes care of the order in  which  metadevices  and  hot
283       spares are created when using the md.tab file.
284
285
286       Example 9 State Database Replicas
287
288
289       This  example  shows  how to set up an initial state database and three
290       replicas on a server that has three disks.
291
292
293         #
294         # (state database and replicas)
295         #
296         mddb01 -c 3 c0t1d0s0 c0t2d0s0 c0t3d0s0
297
298
299
300       In this example, three state database replicas are stored  on  each  of
301       the  three  slices. Once the above entry is made in the /etc/lvm/md.tab
302       file, the metadb command must be run with both the -a and  -f  options.
303       For  example,  typing  the following command creates one state database
304       replicas on three slices:
305
306
307         # metadb -a -f mddb01
308
309

FILES

311           o      /etc/lvm/md.tab
312
313           o      /etc/lvm/md.cf
314

SEE ALSO

316       mdmonitord(1M), metaclear(1M), metadb(1M), metadetach(1M),  metahs(1M),
317       metainit(1M),  metaoffline(1M),  metaonline(1M), metaparam(1M), metare‐
318       cover(1M),  metarename(1M),   metareplace(1M),   metaroot(1M),   metas‐
319       sist(1M),   metaset(1M),   metastat(1M),  metasync(1M),  metattach(1M),
320       md.cf(4), mddb.cf(4), attributes(5), md(7D)
321
322
323       Solaris Volume Manager Administration Guide
324

LIMITATIONS

326       Recursive mirroring is not allowed; that is, a mirror cannot appear  in
327       the definition of another mirror.
328
329
330       Recursive logging is not allowed.
331
332
333       Stripes  and  RAID5 metadevices must contains slices or soft partitions
334       only.
335
336
337       Mirroring of RAID5 metadevices is not allowed.
338
339
340       Soft partitions can be built directly on slices or can be the top level
341       (accessible  by  applications  directly),  but cannot be in the middle,
342       with other metadevices above and below them.
343

NOTES

345       Trans metadevices have been replaced by  UFS  logging.  Existing  trans
346       devices  are not logging--they pass data directly through to the under‐
347       lying device. See mount_ufs(1M) for more information about UFS logging.
348
349
350
351SunOS 5.11                        15 Dec 2004                        md.tab(4)
Impressum