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