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. 1. Is a metadata handler designed to use .write operation to create or delete a raid set? Can I add .create and .delete in "struct dmraid_format"? 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. 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. Anyway, are there any other requirements for DMRAID design? They would be helpful to guide my design. 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
