On Thu, Jun 28, 2007 at 05:23:10PM -0700, Fang, Ying wrote: > Thanks, Heinz. I'd like to estimate the work if I add the creation > function in DMRAID. Please help me figure out the changes. > > Based on my understanding, a metadata handler is designed to provide > data or receive messages via "struct dmraid_format" and use dmraid > internal functions via format.c while Struct lib_context carries the > information center. Correct me if I'm wrong here. That is correct. It uses other support functions beside the ones in format.c as well of course (eg. in misc.c). > 1. Is a metadata handler designed to use .write operation to create or > delete a raid set? No, the write method is for writing or erasing metadata completely only. > Can I add .create and .delete in "struct > dmraid_format"? Yes for .create. Only the metadata format handler should know, which properties the respective native format has. The template should be int (*create)(struct lib_context *lc, struct raid_dev *rd): While going that path, you got to think about any need for *generic* members in the raid_dev structure we need to store RAID device properties the metadata format handler needs. The .delete method (unless we want to erase the metadata completely when we'll use "dmraid -rE") has to get information about the RAID set name (which is the volume name in the isw case). The template should be int (*delete)(struct lib_context *lc, struct raid_set *rs): A successful delete call needs to be followed by a write call per device. We got to think about a way to change layout (eg, remove a mirror leg). > 2. A metadata handler needs build metadata based on several data such as > raid set name, raid level, size, etc. Can they be carried into as a > string argument or a field in "struct lib_context"? It's possible to > build disk sets, raid device sets, and raid set sets too. No, a create_set() function needs adding to the library, which can be called with a struct holding the respective parameters and lists of devices involved. That function will derive properties of raid_dev arguments for the metadata format handler .create method. commands.[ch] need the respective extensions to support the "-C/--create" command line option. > 3. Can I design my own option format to create metadata by DMRAID such > as:"dmraid -ms isw_xxxxxx_raidSet1" (d and D have been used.) to delete > a raid set and "dmraid -f isw -w "isw_xxxx_raidNewSet device-mapper > format" where device-mapper format is "0 1028160 striped 2 256 /dev/sdb > 0 /dev/sdc 0". But I have trouble for nested raid setup and try to use > raid10 or raid51 to identify it. To create a RAID set: dmraid -C isw_xxxxxx_raidSet1 [--layout LAYOUT] [--size X[kmgt]] [DevicePath...] LAYOUT = string types defined in metadata.c (see get_type() function; eg. "mirror"). X = size in KB, MB, GB, TB. In the isw case, which is different from most other metadata format handlers but DDF1, isw.c's create method would need to cover more complex allocation, because other volumes might already be on the devices. To delete a specific RAID set we can add to the existing erase option: dmraid -rE isw_xxxxxx_raidSet1 > > Anyway, are there any other requirements for DMRAID design? They would > be helpful to guide my design. We got to think about adding a spare device to an exiting mirror set (presumably there's mirrored isw volumes only on the remaining device). The above "dmraid -C ..." syntax would allow for that, in case one mirror leg of a volume still exists on a device and we offer another spare to replace the gone disk. Do you need volume resizing ? If so, we got to think about a --resize option. Heinz > > I appreciate your inputs. > > Ying > > -----Original Message----- > From: Heinz Mauelshagen [mailto:mauelshagen@xxxxxxxxxx] > Sent: Thursday, June 28, 2007 2:11 AM > To: ATARAID (eg, Promise Fasttrak, Highpoint 370) related discussions > Cc: Fang, Ying > Subject: Re: create metadata from DMRAID > > On Wed, Jun 27, 2007 at 03:38:32PM -0700, Fang, Ying wrote: > > Hi, > > > > I'm going to provide a function to create isw metadata and looking for > a > > better approach as I have two choices: add the function in dmraid or > an > > application running on top of dmraid. The pro of the former one is > that > > the function will be eventually included in dmraid and distributed by > > RedHat while a stand along utility may not be maintained well in the > > future. The con is the acceptance of my implementation as the current > > source code hasn't set up much ground work on this function yet. I'm > > concerned if I can fulfill the task in a month. I'm looking forward to > > your advice. > > Of course the earlier is the preferred choice, because it'll leverage > the > code to be suitable for other metadata format handlers as well. > > I you've got such time constraint, you may be forced to go for an > interim stand alone tool and we'll migrate the code essentials into > dmraid later... > > Heinz > > > > > > > > > Thanks, > > > > Ying > > > > > _______________________________________________ > > Ataraid-list mailing list > > Ataraid-list@xxxxxxxxxx > > https://www.redhat.com/mailman/listinfo/ataraid-list > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=- > > Heinz Mauelshagen Red Hat GmbH > Consulting Development Engineer Am Sonnenhang 11 > Storage Development 56242 Marienrachdorf > Germany > Mauelshagen@xxxxxxxxxx PHONE +49 171 7803392 > FAX +49 2626 924446 > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=- _______________________________________________ Ataraid-list mailing list Ataraid-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ataraid-list
