lkml.org 
[lkml]   [2018]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [dm-devel] LVM snapshot broke between 4.14 and 4.16
On Fri, Aug 03, 2018 at 03:30:37PM -0400, Mike Snitzer wrote:
>
> I was trying to give context for the "best to update lvm2 anyway"
> disclaimer that was used. Yeah, it was specious.

Well, it seemed to indicate a certain attitude that both Linus and I
are concerned about. I tried to use more of a "pursuading" style to
impress why that attitude was not ideal/correct. Linus used a much
more assertive style (e.g., "Hell, no!").

> And yeah, that isn't a good excuse to ignore it but: dm-snapshot is a
> steaming pile as compared to dm thin-provisioning...

On a side note, this is the first that I've heard the assertion that
dm-thin was better than dm-snapshot. My impression was that
dm-snapshot was a proven code base, that only did one thing and (as
far as I could tell) did it well. In contrast, dm-thin is much newer
code, **far** more complex, with functionality and corner cases
approaching that of a file system --- and just to be even more
exciting, it doesn't have an fsck/repair tool to deal with corrupted
metadata.

In your opinion, is it because you disagree with the assumption that
dm-thin is scary? Or is the argument that dm-snapshot is even
scarier?

- Ted

P.S. It could be that my impression is wrong/out-dated, but the
kernel documentation still says that userspace tools for checking and
repairing the metadata are "under development". As a file system
developer, the reaction this inspires is best summed up as:

https://imgflip.com/memetemplate/50971393/Scared-Face

\
 
 \ /
  Last update: 2018-08-04 07:21    [W:0.178 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site