Re: t_group type raid set

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Wed, Jul 18, 2007 at 05:30:16PM -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'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 ?

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

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

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

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

Heinz

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

[Linux RAID]     [Linux IDE]     [Linux SCSI]     [Kernel]     [Linux Books]     [Linux Admin]     [GFS]     [RPM]     [Photos]     [Yosemite Photos]     [Yosemite News]     [AMD 64]
  Powered by Linux