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

On Thu, Jul 19, 2007 at 03:56:08PM -0700, Fang, Ying wrote:
> >> >> 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.

And for trivial metadata formats, delete_raidsets() would just delete
the one and only raid set.

> 
> >>
> >> 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. 

Hrm, why ?

Rather than getting metadata dicovered by the format handlers .read() function
you'ld call .config() multiple times indirectly from discover_raid_devices(),
which will create the raid dev structures, hence enabling you to call
build_sets() afterwards.
The *dmraid_read() functions would need changing to *dmraid_get()
and discover_raid_devices would receive an API change to take an
argument to either try retrieving metadata from the device or create it
via .config().

Heinz

> 
> >>
> >> 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
> 
> _______________________________________________
> Ataraid-list mailing list
> [email protected]
> https://www.redhat.com/mailman/listinfo/ataraid-list