Re: GEOM strange error
On 13/03/2018 13:52, Eugene Grosbein wrote: > 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. I don't know what it should do, but I see that it doesn't do it in the "idle" state. However, when the stripe itself is opened / accessed, then it does add the exclusive bit to requested access counts. See g_stripe_access(). I think that what you expected makes more sense for me than what the code actually does. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: GEOM strange error
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. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: GEOM strange error
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. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
GEOM strange error
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? ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
