Received: by 2002:a89:2c3:0:b0:1ed:23cc:44d1 with SMTP id d3csp1161105lqs; Wed, 6 Mar 2024 08:00:25 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCWdH4x5ef9sPhhXrwUZAiUqgz/ekeat4xdOlNuJSgpn0YKUtoMBC+EVn9hioLvP76Bah+gA5luqvNiOpYIV7erdgP1C1C3rOd6k9tF7+g== X-Google-Smtp-Source: AGHT+IFh9RRGXcZYNxuIzjUADBGwWrtlv0CJXM3pLhcuteCE32KIBJHhLEi5N+IowGpdpbLRceBP X-Received: by 2002:a0d:cec1:0:b0:609:18e2:91b2 with SMTP id q184-20020a0dcec1000000b0060918e291b2mr14729648ywd.32.1709740825608; Wed, 06 Mar 2024 08:00:25 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709740825; cv=pass; d=google.com; s=arc-20160816; b=zisuVgv+yn51HDpMHd6FX0RTGeVFyKvkTJbRJmTiD5eQDYJ76Zy8fbxdZLkKJOutKk fTzDj0wQvnWZM0YYhEiY/F5vpvo6GyRBX42OswSvgh/AxmVBqzikTVZpjiDH6GMaeqlE +CPW6boGkayTAioys5yhjwev0xeHkjAAycyhC4tCJx0YYnJwXMN9zXjd8pI/rhyj+QlS uglshbd6KRmd9RjG2wBVF27cD0UGcHVz4CzMlMN/jiSgiC+a/p4V/FLczhnGR1y5pQpM 4cTMhxv8p58Gz5rgeWN2+lo9CzPWqt/kUtoSmjpXbzFBuWHOdwLkWaPlkU5pm8yG1C8z Ygog== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:subject:cc:to:from:date:dkim-signature; bh=wIIdw8ckHvVn5igXTzUjHRLg6rvzXoUvv9uYoYgw/8Q=; fh=Ly3vSks3fdCGkCRPs6aDdo/7vhL6tZM4k6TW9GhIqQ4=; b=Xpq0Zfpc/JZ0QsDT92xIJHTj/VDA2POVg4/dbSzo2bl8cKmGHOp9hvMOhuk3QYwPcV IWeaYdomeEYFdWOD1yTAWZ9scikcr9sgJaybEQVjjn7+UmQjNGcT+xVDA2MLbBqCuBOl q47pYc5o0Pat4Gh8EoPjUXyJ4AuZKFi7ysfFqTX5O1LftHrxjQy1lWkFdjileZrR9xuj sjgiGiUtw9q6hYLkhgk1ciKvd7S9H8YuZn6N/ckstApRoV7j2X/hnHEYtv5NzGTXPNmB ffjTtMrKcXUfy6KkFZ3zod7AxYIMTSgEUJhBgcDXspEgVGWH+u4mTSn9NJUT1z7VS5kZ 1HXQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=NUaidoa8; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-94212-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-94212-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id y16-20020a05622a121000b0042ec0777b8fsi2962076qtx.145.2024.03.06.08.00.25 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Mar 2024 08:00:25 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-94212-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=NUaidoa8; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-94212-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-94212-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id A467D1C2271E for ; Wed, 6 Mar 2024 16:00:24 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1298C135A6F; Wed, 6 Mar 2024 16:00:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="NUaidoa8" Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9BD815DF3C for ; Wed, 6 Mar 2024 16:00:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709740813; cv=none; b=cFreS/RoC70NAJzHDKASCOG5eme8qGSs8997v4DOELFmFojj/6uEZV3mNJ+v3wnrNeQlmx/p90TSUfO91QpVTK+XZalYoGOaBqE/w/L2/VywWZDP7ZlP2kIYcQyVEsIHQjIO0/ewF+iWbqaH4LYyIez9fz/y/gxHH+gxeBcJEUU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709740813; c=relaxed/simple; bh=yErQmxsqshrBcM8l6AwNJI7JsDiBKwPq6xd5fRjHqwk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ReRwn8GHylXepzeXKzeOGlzZGurpIVYdbkz5pwlvhOtTAFSQPiKJ4F9zq5jWfxtfi11b53smEZ25rtGx7uQekVz726Gl6hJsaXrArL7KAQlWwj5w5khGyQiwE9EpSR3Lk1ZvA2mmayKK0obos8HamqEyxF5sQYLjjCho8rO7Glk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=NUaidoa8; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709740810; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wIIdw8ckHvVn5igXTzUjHRLg6rvzXoUvv9uYoYgw/8Q=; b=NUaidoa8pyoMf/h2TS5oJDfPIGfdPRjRl+lWMQbckUrEIUiouTZMAHGL1Pv7Uk4ZtvooY9 PRBjpGnv61nkAa0fdBdRlo9a9Lt/DJBJGpzWEyCdxc+Ia/eDqDrd6cCPm2Ppen1nBuxm1m VgV/UiF4InMmji/dzpeuSt5Pb5JzbrY= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-318-VkHvEyVUPY-rUx7UgScF8w-1; Wed, 06 Mar 2024 11:00:08 -0500 X-MC-Unique: VkHvEyVUPY-rUx7UgScF8w-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 184761C54062; Wed, 6 Mar 2024 16:00:08 +0000 (UTC) Received: from fedora (unknown [10.72.116.47]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6165D200AD5B; Wed, 6 Mar 2024 16:00:01 +0000 (UTC) Date: Wed, 6 Mar 2024 23:59:57 +0800 From: Ming Lei To: Mike Snitzer , Patrick Plenefisch Cc: Goffredo Baroncelli , linux-kernel@vger.kernel.org, Alasdair Kergon , Mikulas Patocka , Chris Mason , Josef Bacik , David Sterba , regressions@lists.linux.dev, dm-devel@lists.linux.dev, linux-btrfs@vger.kernel.org Subject: Re: LVM-on-LVM: error while submitting device barriers Message-ID: References: <672e88f2-8ac3-45fe-a2e9-730800017f53@libero.it> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.4 On Tue, Mar 05, 2024 at 12:45:13PM -0500, Mike Snitzer wrote: > On Thu, Feb 29 2024 at 5:05P -0500, > Goffredo Baroncelli wrote: > > > On 29/02/2024 21.22, Patrick Plenefisch wrote: > > > On Thu, Feb 29, 2024 at 2:56 PM Goffredo Baroncelli wrote: > > > > > > > > > Your understanding is correct. The only thing that comes to my mind to > > > > > cause the problem is asymmetry of the SATA devices. I have one 8TB > > > > > device, plus a 1.5TB, 3TB, and 3TB drives. Doing math on the actual > > > > > extents, lowerVG/single spans (3TB+3TB), and > > > > > lowerVG/lvmPool/lvm/brokenDisk spans (3TB+1.5TB). Both obviously have > > > > > the other leg of raid1 on the 8TB drive, but my thought was that the > > > > > jump across the 1.5+3TB drive gap was at least "interesting" > > > > > > > > > > > > what about lowerVG/works ? > > > > > > > > > > That one is only on two disks, it doesn't span any gaps > > > > Sorry, but re-reading the original email I found something that I missed before: > > > > > BTRFS error (device dm-75): bdev /dev/mapper/lvm-brokenDisk errs: wr > > > 0, rd 0, flush 1, corrupt 0, gen 0 > > > BTRFS warning (device dm-75): chunk 13631488 missing 1 devices, max > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > tolerance is 0 for writable mount > > > BTRFS: error (device dm-75) in write_all_supers:4379: errno=-5 IO > > > failure (errors while submitting device barriers.) > > > > Looking at the code, it seems that if a FLUSH commands fails, btrfs > > considers that the disk is missing. The it cannot mount RW the device. > > > > I would investigate with the LVM developers, if it properly passes > > the flush/barrier command through all the layers, when we have an > > lvm over lvm (raid1). The fact that the lvm is a raid1, is important because > > a flush command to be honored has to be honored by all the > > devices involved. Hello Patrick & Goffredo, I can trigger this kind of btrfs complaint by simulating one FLUSH failure. If you can reproduce this issue easily, please collect log by the following bpftrace script, which may show where the flush failure is, and maybe it can help to narrow down the issue in the whole stack. #!/usr/bin/bpftrace #ifndef BPFTRACE_HAVE_BTF #include #endif kprobe:submit_bio_noacct, kprobe:submit_bio / (((struct bio *)arg0)->bi_opf & (1 << __REQ_PREFLUSH)) != 0 / { $bio = (struct bio *)arg0; @submit_stack[arg0] = kstack; @tracked[arg0] = 1; } kprobe:bio_endio /@tracked[arg0] != 0/ { $bio = (struct bio *)arg0; if (($bio->bi_flags & (1 << BIO_CHAIN)) && $bio->__bi_remaining.counter > 1) { return; } if ($bio->bi_status != 0) { printf("dev %s bio failed %d, submitter %s completion %s\n", $bio->bi_bdev->bd_disk->disk_name, $bio->bi_status, @submit_stack[arg0], kstack); } delete(@submit_stack[arg0]); delete(@tracked[arg0]); } END { clear(@submit_stack); clear(@tracked); } Thanks, Ming