Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2451524imm; Thu, 2 Aug 2018 11:49:11 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcrNky44Au3EXru1MVfTVgYtCbXpFzWiGrKCM+t8ue4d3e2rrL+xPy4tGTPY+G6PmHpGIWV X-Received: by 2002:a63:41c6:: with SMTP id o189-v6mr601602pga.323.1533235751846; Thu, 02 Aug 2018 11:49:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533235751; cv=none; d=google.com; s=arc-20160816; b=t6N6HwHdagW0LLY+2H+XiahauVz2CGaXYjmqYwGSsR1C2O44eMKYO90Z1uYz8hdW0S 013hS3C2avYLLOUxOg68Cws/cp5okuWsoTV12aGa6hITXYhha+FVNTZPXqE8rgd2DQEo E6l3PyaKmLz6ZCsrZiwQc0F19IkQYF8uC76W9qvYvuAVyQ0mhS9jwRGByefC1z/LW/oR IB/b1/vBseo35BeKXRw3E/CtB+fsGy8+8wjDTNYUdS5wO9FR9ExS7Am0kbCDUidKfyQ1 u+xlaAdcme6tUVG46LZill2cmVP9Lb2t8zceeNs+ik3T7cVK9gr7NFzYOiRQJ5hHpaEq nySw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=qpMOWRt7le5biLh1CHAb4XmKD2c1UF2xEbHu3Kryc0o=; b=lPx8YY99BPDrL3aRH43GtCnY8Ra390RS0cCCIXOiVdh65nyDYLFJ8rug8uc0ybeWnO 5rQJ9lcD/56wT8M9RqPhEG+9V+KA7WwDF595Bfnl2GykJbIBB1JrYcTE6creUiHJHjgR FBCSepzXe350vPSxr8ENNPr/leNaj7tbAEeQAqquxOmHbyi72NubMKRiLw74Ja1yGGXl y7cKrW5evbVNv1b4SQKg7wRFW2tG3/+Aspf3LtjGscHTit5KvdyRdtBu3yIbLnJ1iHMC Qbsfg3LWE9ZlpSFysq9qcwI4ZD7nSm8Yzf2KgU7vxVrH+Q0X6jzQRepMmUsYZMviiEpV 2Aww== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=MwJe+2C8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s198-v6si2207659pgc.381.2018.08.02.11.48.57; Thu, 02 Aug 2018 11:49:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=MwJe+2C8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387856AbeHBUZZ (ORCPT + 99 others); Thu, 2 Aug 2018 16:25:25 -0400 Received: from mail-it0-f44.google.com ([209.85.214.44]:35549 "EHLO mail-it0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387512AbeHBUZY (ORCPT ); Thu, 2 Aug 2018 16:25:24 -0400 Received: by mail-it0-f44.google.com with SMTP id q20-v6so4882111ith.0; Thu, 02 Aug 2018 11:33:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qpMOWRt7le5biLh1CHAb4XmKD2c1UF2xEbHu3Kryc0o=; b=MwJe+2C8SptE6g48pPjg/faV3cum+Wqbggs4vox3Y7/MZcTWx/XPR69P7VzhWleL6Y HsQqPsMDEZeZAiGJ2Y3iMv7Q7YApNEp9NCtoxptrotwnfCnaUtjuGLEUxo9aADcYOBDJ +P/5HqGq9cj9ilXjdCsLOlFpqmXaY6ZeaLdpY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qpMOWRt7le5biLh1CHAb4XmKD2c1UF2xEbHu3Kryc0o=; b=sAcla8G+/zhpf9HiYodionQCnrKbR6Kr4ccoXWwxZpNGOkqbExR90mrhsP9rAJEPo0 Iqb5512ejjDkfeWv1r6MxnzvfgJZmPx5uGbCHmkKlGxwOyJxBsJ4YUWqufrXsLT4oHox BwLTmAI6YM04BcHOIphIjUe2MTHPpfd386wiAH3Z9gvRyDlFj+hklXZQRO5LbbbOyX84 mdZ9Fo2L4hhkgEjUW+/sOUDqOCzjYow5/3T7OynpKb02TIw6IR2VE9YUWrApnZfqE4oL N32MCGKtWTB7ZC/Jtt58eEKSPUWosrqQDIMMGZPg5wk2ZXPtxEb3X9unVLsiHsrdr5Tq tIkQ== X-Gm-Message-State: AOUpUlHeheuSbrz+fRlwpBaTAQ0KUf8C17oImdD1Rsfp5AJ/1346JUTw 8ETL83s7M+/xgOMsNnTW6tm9AdF6Gv5+LA6nUSM= X-Received: by 2002:a24:94f:: with SMTP id 76-v6mr3619805itm.113.1533234785792; Thu, 02 Aug 2018 11:33:05 -0700 (PDT) MIME-Version: 1.0 References: <226835ba-2197-b850-6e5b-8ba14f7fd016@torlan.ru> <93bff248-6897-4867-841b-2dace11597de@torlan.ru> In-Reply-To: From: Linus Torvalds Date: Thu, 2 Aug 2018 11:32:54 -0700 Message-ID: Subject: Re: LVM snapshot broke between 4.14 and 4.16 To: Ilya Dryomov Cc: wgh@torlan.ru, Jens Axboe , linux-block , Linux Kernel Mailing List , Sagi Grimberg , Mike Snitzer , dm-devel@redhat.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 2, 2018 at 11:18 AM Ilya Dryomov wrote: > > I think it was my commit 721c7fc701c7 ("block: fail op_is_write() > requests to read-only partitions"). The block layer was previously > allowing non-blkdev_write_iter() writes to read-only disks and > partitions. dm's chunk_io() boils down to submit_bio(), so in 4.16 > it started to fail if the underlying device was marked read-only. Ugh. That commit does look like the obviously right thing to do, and our old behavior was obviously wrong. At the same time, we really really shouldn't break user flow, even if that flow was due to an obvious bug. Dang. > Apparently at least some versions of lvm(8) instruct dm to mark the COW > device read-only even though it is always written to. It comes up only > if the user asks for a read-only snapshot (the default is writable). > > One option might be to ignore the supplied DM_READONLY_FLAG for COW > devices. Marking the COW device (i.e. the exception store) read-only > is probably never sane... That sounds like possibly the sanest fixlet for this - perhaps together with a warning message saying "ignoring DM_READONLY_FLAG for COW device" so that people see that they are doing insane things. But some of our internal DM_READONLY_FLAG use obviously comes from other sources that we have to honor (ie some grepping shows me code like if (get_disk_ro(disk)) param->flags |= DM_READONLY_FLAG; where we obviously can *not* override the get_disk_ro() state. So it depends a lot on how this all happened. But it looks like in this particular case, it all came from one inconsistent lvmcreate command. Or - if there really is only _one_ user that noticed this, and a new lvm2 release fixes his problem, maybe we can say "we broke it, but the only person who reported it can work around it". WGH (sorry, no idea what your real name is) - what's the source of the script that broke? Was it some system script you got from outside and likely to affect others too? Or was it just some local thing you wrote yourself and was unintentionally buggy and nobody else is likely to hit this? Because if the latter, if you can work around it and you're the only user this hits, we might just be able to ignore it. Linus