Goal
Creating a metadevice
Command
form meta from dev SymDevName, config=MetaOption [, stripe_size=<MetaStripeSize>[cyl]] [, count=<member_count>];
IO Impact/Restrictions
When managing metadevices, data is not written directly to the devices involved, and therefore the original data is, essentially, preserved. However, due to the reorganization upon completion of the device management actions, the host is unable to access all of the original data. Therefore, it is the responsibility of the attached host to handle the change to the physical geometry of the device.
Note: The expansion of striped metadevices is an exception to this rule. In this case, you can provide a BCV meta to preserve the original data, which will be rewritten to the newly configured striped meta. Table Below lists the possible data management operations and their effects on data integrity.
a. Preserved up to where the metadevice is removed.
b. Preserved but there is no host component to piece the data together.
c. Protection is a user-configurable option.
Example
Example 1
In the first example, it is to form a concatenated metadevice 0010 and add metamembers of 0011 and 0012.
symconfigure -sid 1234 -v -f metafile commit
Where metafile contains:
form meta from dev 0010, config = concatenated;
add dev 0011:0012 to meta 0010;
Example 2
the second example is to form a striped metadevice 0010 and add metamembers 0013 and 0014 using stripe size of 1920.
symconfigure -sid 1234 -v -f metafile commit
Where metafile contains:
form meta from dev 0010, config = striped, stripe_size=1920;
add dev 0013:0014 to meta 0010;
Example 3
in example 3, it is to create meta device with 0010 as its meta head and three other members selected from the pool of unmapped devices.
symconfigure -sid 1234 -v -f metafile commit
Where metafile contains:
form meta from dev 0030, config = striped, stripe_size=1920, count=4;