Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1866769imm; Sat, 4 Aug 2018 12:39:57 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcI98hXtr8DWFRqcg/eOFiScBPCzESpxsb8wQ4J3+7eR1cHDIx+S6iG/KU06waxnuAbOIaB X-Received: by 2002:a62:ce81:: with SMTP id y123-v6mr10275895pfg.95.1533411597718; Sat, 04 Aug 2018 12:39:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533411597; cv=none; d=google.com; s=arc-20160816; b=NdpOPMMdj6O1fSWzxyE7Z14dNGJ2C8c1WUeCJcnf1tsc4KLWMC+qO3dQ13BZs5pojS +snDNiaKOsXXN2rm9AUXGa2BqpQF26TJC+cDK4PAMa7oHEzh6vx37bm8kREQdXTtL2CR RwMxyQ7xd8CSC356drRHZQ4IMr3ya1WgHXUAvdczJLyJasjl9UXIkNzYSgVJZzbzoOvJ l88rWJ3u/q+yCORk0tf9cD50UeQXVr0omgw8HAdrf2m2BeEH8Hw7b+Qo9bAJXzK+DhNV lM1n/hQm63z+rVm9EhCV58wGvOCquSNiyT9dmZY6EEimBFuqkEIILI6vjdNrDXXFtNp0 1IXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=6MCOIu8MrzxB5SFwERmgaFIs98/2D549kY2wye9tBfs=; b=pfYSaMyqLl/+pTaAKRdqRoDHS+h1f0vZLL1ls1TqTOga18g9inxptEwKnxc3LPGcSU oXEah71FsoN78xooa9NtPu+UkI6GoxVUsJHICdmFMAfQwGwt+ynvMuRwf8g50WS30DSs cuuzbmS0ycFnMRQrakavEz96yK2wS8uiwWsD6+2O29Q0LijwQf5A2DsdIwAo6R//WgUi eDnVF2lYOaclF3aqRmR9vlU1EROl4C6u5zLfmXKBvFUZUjjb3x4qJK5GSIF+/mf7ECjJ OcRtqBsWZMSAPNe+QY/pwTujcFl87JYq/h/gjHqntORroeZSL1R/7KJqExrv/K5k9Ag+ MsBg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@thunk.org header.s=ef5046eb header.b="T/22jwqQ"; 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 d36-v6si6313282pla.446.2018.08.04.12.39.31; Sat, 04 Aug 2018 12:39:57 -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=fail header.i=@thunk.org header.s=ef5046eb header.b="T/22jwqQ"; 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 S1729600AbeHDVjr (ORCPT + 99 others); Sat, 4 Aug 2018 17:39:47 -0400 Received: from imap.thunk.org ([74.207.234.97]:37762 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728067AbeHDVjr (ORCPT ); Sat, 4 Aug 2018 17:39:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=6MCOIu8MrzxB5SFwERmgaFIs98/2D549kY2wye9tBfs=; b=T/22jwqQIcaSkm2OJv5TxCmxkc wDnPu9jAQgs/rOw9RYerJXDj64WAQVgjRXiCRQeuABBuYqStaZxDneNS3HS0IC8/QX9UijVn+jM6U cBql0ZQveTOZYzpou/PQSKGe1SM/GWUQvJX7QvZ75di2PqhNt7TcfG02JaFC4KXPEmiI=; Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.89) (envelope-from ) id 1fm2N8-0001WE-O0; Sat, 04 Aug 2018 19:37:54 +0000 Received: by callcc.thunk.org (Postfix, from userid 15806) id D53587A64C9; Sat, 4 Aug 2018 15:37:53 -0400 (EDT) Date: Sat, 4 Aug 2018 15:37:53 -0400 From: "Theodore Y. Ts'o" To: Mike Snitzer Cc: Zdenek Kabelac , Linus Torvalds , Jens Axboe , Sagi Grimberg , Linux Kernel Mailing List , linux-block , dm-devel@redhat.com, Ilya Dryomov , wgh@torlan.ru Subject: Re: LVM snapshot broke between 4.14 and 4.16 Message-ID: <20180804193753.GC4461@thunk.org> Mail-Followup-To: "Theodore Y. Ts'o" , Mike Snitzer , Zdenek Kabelac , Linus Torvalds , Jens Axboe , Sagi Grimberg , Linux Kernel Mailing List , linux-block , dm-devel@redhat.com, Ilya Dryomov , wgh@torlan.ru References: <20180803185431.GB3258@redhat.com> <20180803193037.GA4581@redhat.com> <20180804052033.GA4461@thunk.org> <102c2d75-f768-a649-52c3-bac6f0ca738d@redhat.com> <20180804162205.GB4461@thunk.org> <20180804181845.GA10499@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180804181845.GA10499@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Aug 04, 2018 at 02:18:47PM -0400, Mike Snitzer wrote: > > Fair enough. I don't think I would consider that makes dm-snapshot a > > "steaming pile". For me, protection against data loss is Job One. > > What's your point Ted? Do you have _any_ intention of actually using > anything DM or is this just a way for you to continue to snipe at it? My point is that putting down dm-snapshot by calling it a "steaming pile" because it can't perform well on workloads that weren't a requirement when it was first designed is neither accurate nor fair. And steering users away from it by badmouthing to a technology which ever so often, requires enterprise support to recover, is something that *I* at least would classify as "marginal". Maybe it's just that file system developers have higher standards. I know that Dave Chinner at LSF/MM commented that using some of the things he has been developing for XFS subvolume support might be interesting precisely because it could provide some of the facilities currently provided by thin provisioning (perhaps not all of them; I'm not sure how well his virtual block remapping layer would handle hundreds of snapshots) but with file system tools which have a lot more seasoning and where people have spent a lot of effort on data recovery tools. In any case, I do use DM quite a lot. I use LVM2 and dm-snapshot (and it's been working just *fine* for my use cases). I've wanted to use dm-thin, but have been put off by it being labeled as experimental and by some of the comments about how robust its recovery tools are. If there was documentation about how an advanced user/developer could use low level tools to do manual repair of a thin pool when the automated procedures didn't work, without having to pay $$$ to some company for "enterprise support", I'd be a lot more willing to give it a try. Sorry, I just care a *lot* about data robustness. > Maybe read your email from earlier today before repeating yourself: > https://lkml.org/lkml/2018/8/4/366 Apologies. I'm currently staying at an Assisted Living facility keeping an eye on my Dad this week, and the internet at the senior living center has been.... marginal. As a result I've been reading my e-mail in batches, and so I hadn't seen the e-mail you had posted earlier before I had sent my reply. - Ted