create metadata from DMRAID
mauelshagen at redhat.com
Fri Jun 29 14:05:29 UTC 2007
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
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
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;
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.
> I appreciate your inputs.
> -----Original Message-----
> From: Heinz Mauelshagen [mailto:mauelshagen at redhat.com]
> 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
> > better approach as I have two choices: add the function in dmraid or
> > application running on top of dmraid. The pro of the former one is
> > 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
> 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...
> > Thanks,
> > Ying
> > _______________________________________________
> > Ataraid-list mailing list
> > Ataraid-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/ataraid-list
> Heinz Mauelshagen Red Hat GmbH
> Consulting Development Engineer Am Sonnenhang 11
> Storage Development 56242 Marienrachdorf
> Mauelshagen at RedHat.com PHONE +49 171 7803392
> FAX +49 2626 924446
More information about the Ataraid-list