RE: Ataraid-list Digest, Vol 41, Issue 13

>> >> Hello,
>> >>
>> >> I'd like to know if the t_group type of raid set is mandatory or
>> >> optional if a group of disks can hold more than one raid sets,
such
>> as
>> >> ISW's volumes.
>> >
>> >It is optional.
>> >I designed it to address the needs of metadata formats such as isw
or
>> ddf1.
>> >
>> It would be much better to have a separate data structure for a
t_group
>> type raid set where I can store the information of a disk group. But
I
>> can live with it.
>
>?
>
>Using one and the same structure (ie. struct raid_set) with the type
>to identify its purpose looks simpler than having too many different
>structures IMHO.
>
I agreed with you until I saw some people intended to skip the t_group
raid set layer and some people got confused. Anyway, that's just my
personal opinion.

>>
>> I'm going to do some implementation based on the following changes
and
>> I'd like to get any advice from you.
>>
>> 1. Create a new function called config in struct dmraid_format. It
makes
>> new metadata according to a t_group type raid set and updates all
raid
>> device's meta_areases. Because ISW needs a t_group set to gather all
>> volumes I limit current version to only support a t_group raid set.
>> Later on other people can add their code to support a simple raid set
or
>> whatever they want. The benefit for the config function is that it
>> provides a general service and can be used by some functions, such as
>> volume deletion, volume creation, and volume and/or disk's
status/state
>> change.
>
>Sounds good.
>Can you elaborate on the prototype to make this more clear ?
>


I give the control flow of volume deletion below:
1. Create _delete_raidsets(lc, ?) in metadata which is involved by
_perform as a entry of struct prepost prepost[]. 
2. In the function, it first deletes the raid set representing the
desired volume. That means it remove the corresponding raid set from the
set list of a t_group raid set.
3. If the set list isn't empty, it invokes fmt->config(lc, rs_group) to
rebuild metadata with the current raid configuration. Besides metadata
building, the format handler iterates each raid device listing in
rs_group->devs, and replaces metadata area defined in struct raid_dev's
meta_areas->area with the new one.
4. _delete_raidsets then iterates each raid device and calls fmt->write
to write metadata.

>>
>> 2. Create a function in metadata to handle volume deletion. This
>> function removes a raid set from its parent(t_group raid set). If
there
>> is any volume left in its parent set, it calls the above config
function
>> to update metadata and write the metadata back to all involved disks.
>
>Presumably the .config() and the .write() calls will be seperate
>as we discussed before ?
>

See above.

>> Otherwise it simply erases metadata from the corresponding disks. The
-s
>> option may be used for a user to input volume name but that
information
>> gets lost after build_sets function is invoked.
>
>Hrm, the name will be kept with the created raid set struct(s). No ?
> 
This name is an existing name to get deleted.

>> I can either to add the
>> volume name into field arg of struct lib_options or require the
delete
>> option carrying the volume name. I don't have preference at this
moment.
>> Any suggestions?
>
>Call .config() per raid device on the command line, hence
>adding those to the RD list of lib_context, call build_sets()
>afterwards and the sequence of .write() calls lastly ?
>

I need run build_sets() function first to generate a structure of a
t_type raid set and its subsets. 

>>
>> 3. Create a function in metadata to handle volume creation. This
>> function creates a new raid set to represent the properties of a
volume,
>> makes new metadata and writes to disks. I'll look at the input
arguments
>> soon.
>
>Which will be called from the command layer, right.
Yes.

Ying