Re: LVM snapshot broke between 4.14 and 4.16

From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Mike Snitzer <snitzer@redhat.com>
Cc: Zdenek Kabelac <zkabelac@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>, Sagi Grimberg <sagi@grimberg.me>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-block <linux-block@vger.kernel.org>,
	dm-devel@redhat.com, Ilya Dryomov <idryomov@gmail.com>,
	wgh@torlan.ru
Subject: Re: LVM snapshot broke between 4.14 and 4.16
Date: Sat, 4 Aug 2018 15:37:53 -0400	[thread overview]
Message-ID: <20180804193753.GC4461@thunk.org> (raw)
In-Reply-To: <20180804181845.GA10499@redhat.com>

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