Re: t_group type raid set

Heinz Mauelshagen <[email protected]>
Newsgroups gmane.linux.ataraid
Message-ID <[email protected]>
On Wed, Jul 18, 2007 at 05:30:16PM -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'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 ?

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

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

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

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

Heinz

> 
> Thanks,
> Ying
> 
> _______________________________________________
> Ataraid-list mailing list
> [email protected]
> https://www.redhat.com/mailman/listinfo/ataraid-list
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.