On 13.03.2018 17:39, Andriy Gapon wrote:> On 13/03/2018 11:37, Eugene Grosbein wrote:
>> Hi!
>>
>> Let's create a stripe and GPT over it using test files as backing
store:
>>
>> truncate -s 1G d0
>> truncate -s 1G d1
>> mdconfig -af d0 # gives md0
>> mdconfig -af d1 # gives md1
>>
>> gpart create -s GPT md0
>> gpart create -s GPT md1
>> gpart destroy -F md1
>> gpart destroy -F md0 # no errors still
>>
>> gstripe label -s $((128*1024)) st0 md0 md1
>> gpart create -s GPT /dev/stripe/st0
>> dmesg -a
>>
>> GEOM_STRIPE: Device st0 created (id=4000112224).
>> GEOM_STRIPE: Disk md0 attached to st0.
>> GEOM_STRIPE: Disk md1 attached to st0.
>> GEOM_STRIPE: Device stripe/st0 activated.
>> GEOM: md0: corrupt or invalid GPT detected.
>> GEOM: md0: GPT rejected -- may not be recoverable.
>>
>> Why does it emit such md0-related error?
>
> When GPT is placed on st0 it's opened for writing and, thus, md0 and
md1 are
> open for writing too. Afterwards, the write access count is cleared from
three
> of them and that triggers re-tasting. I guess that g_part code tries to
taste
> md0 and md1 and sees the GPT label at the start of md0 and the label is
> correctly rejected because it's inconsistent with md0's parameters.
Shouldn't gstripe grab its components for exclusive access?
So that GEOM does not even try to treat md[01] as targets for re-tasting.