On Wed, Jun 07, 2006 at 10:54:28AM -0700, Darrick J. Wong wrote:
> Molle Bestefich wrote:
> > Heinz Mauelshagen wrote:
> >> > But, I suppose it wouldn't be too difficult to reroll the patches to do
> >> > it that way too.
> >>
> >> That would be great, thanks.
> >
> > Why would that be a better solution?
>
RAID devices were meant to define the underyling device
(typically a disk) per se, having one RAID set mapped onto
a group of RAID devices.
The simple volume management some vendors (and SNIA) build into their RAID
solutions, forced the ability to map multiple RAID sets onto the same group
of RAID devices, hence the idea of having a special 'group' RAID set as used
for isw.
> I'm not sure. I like my solution better, because any additional
> raid_devs that get created after the first one are explicitly marked as
> clones, and the name/di/fmt/meta_areas fields all point to the
> corresponding fields in the first one. The isw code does essentially
> the same thing by (if I'm reading the code correctly) creating
> additional raid_devs with shared private_ptrs and meta_areas = NULL, but
> you'd have to know that isw is doing that to sort things out.
Sure.
>
> Actually, come to think of it, it seems like a bad idea to have
> raid_devs floating around with NULL meta_areas, because any core code
> that depends on meta_areas pointing to some real data would become
> confused. That said, I can't think of any code that does that... yet.
The idea is to access the ones hanging off the special 'group' set,
which is a special case in the core code, gaining direct access to
the underyling devices (i.e. those of type, which need e.g. metadata updates.
Having a clone flag would just be a different approach to achieve the
same thing.
> Though I wonder what isw_write will do if you call it on a secondary
> raid_dev, because isw_write uses META(), which depends on meta_areas.
It won't be called for that, only for t_group type RAID devices.
>
> --D
>
--
Regards,
Heinz -- The LVM Guy --
*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ataraid-list
