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