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 > Ataraid-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/ataraid-list _______________________________________________ Ataraid-list mailing list Ataraid-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ataraid-list
