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? 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. 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. 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. --D
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ataraid-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ataraid-list
