From owner-freebsd-stable@freebsd.org Tue Mar 13 12:14:15 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3AE33F464D0 for ; Tue, 13 Mar 2018 12:14:15 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com [209.85.215.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8BCEA79D9F; Tue, 13 Mar 2018 12:14:14 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f48.google.com with SMTP id m69-v6so28380328lfe.8; Tue, 13 Mar 2018 05:14:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8PHnlDJvuxS5bXpPQr8jPG/TaXTbwXQCdGiJ4ugsD8Y=; b=TSLF03r8/YCc2sVrTdR1vb9kKmUjIfH393jaWBGuy35410aQAPuxcxJmYqnEH2e93h LyQOqn4xpSGkLchWepOS9TQ9f3/vM5+24tfWFDe9c04r1KEF0wrUb/ar1EFNdFQkuORd 2LMytdr++NqjP3dcu0G3Y6AV32K96PLOXhHYQN1J4nErKroXYGzLU+o1pCOfSgAs2M3/ Eief0k/9SCI5D5uOfCdztyabyJqa4MZdxpN7Dp2MbIggeFO3HVXIdZBVByxvcNFJ9LeX LFAHJzA6UsO2/lzONH3wp0Rv71RvYNGeBCGrJTN+YrDIQ2TDiYZxXPpR780C3UlG1Wib N6lw== X-Gm-Message-State: AElRT7EYxoI9lm0tp9zqK6OGINZXGK9kdBCk/PzFMBR8eQurX5iRNFqh lQxvE47J1xYzw080Jy7CkjYai0gJ X-Google-Smtp-Source: AG47ELudD16Vz6DZ9g8nrbDsEnqSDfysucOA5dnvd/uQXUe0NJUDkKNFhPPZOJrxkVBcgrtzSKP+IQ== X-Received: by 10.46.89.28 with SMTP id n28mr292312ljb.73.1520943246688; Tue, 13 Mar 2018 05:14:06 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id h23-v6sm12308lfj.87.2018.03.13.05.14.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 05:14:05 -0700 (PDT) Subject: Re: GEOM strange error To: Eugene Grosbein , FreeBSD Stable Cc: Alexander Motin References: <5AA79BBC.70009@grosbein.net> <5AA7BB73.7090008@grosbein.net> From: Andriy Gapon Message-ID: <13234bc1-5c04-1d6b-83e8-21282b038eaa@FreeBSD.org> Date: Tue, 13 Mar 2018 14:14:04 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <5AA7BB73.7090008@grosbein.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 12:14:15 -0000 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