t_group type raid set

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


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

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.

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

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.

Thanks,
Ying

_______________________________________________
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