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
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
