linux-kernel - Re: [dm-devel] LVM snapshot broke between 4.14 and 4.16

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <102c2d75-f768-a649-52c3-bac6f0ca738d@redhat.com>
Date:   Sat, 4 Aug 2018 10:36:50 +0200
From:   Zdenek Kabelac <zkabelac@...hat.com>
To:     "Theodore Y. Ts'o" <tytso@....edu>,
        Mike Snitzer <snitzer@...hat.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Jens Axboe <axboe@...nel.dk>, Sagi Grimberg <sagi@...mberg.me>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-block <linux-block@...r.kernel.org>, dm-devel@...hat.com,
        Ilya Dryomov <idryomov@...il.com>, wgh@...lan.ru
Subject: Re: [dm-devel] LVM snapshot broke between 4.14 and 4.16

Dne 4.8.2018 v 07:20 Theodore Y. Ts'o napsal(a):
> 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!").

My whole point was - when someone has 'enough time' to compile fresh new 
kernel, spending couple seconds to build also recent lvm2 should have be no 
issue. Bugs are continually fixed, new feature from newer kernel are being
used, known problems are being addressed - that's  all what it means.
Bug are fixed not just in kernel, but also in user-space.

> 
>> 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?

dm-snapshost has really outdated design - it's been useful in the old age 
where megabyte was hell lot of space.

Nowadays, when users do need to handle snapshots in multi gigabyte sizes and 
moreover have number of snapshots from the same volume taken over the time, 
want to take snapshot of snapshot of snapshot, the old snapshot simple kills 
all the performance, uses tons of resources and becomes serious bottleneck of 
your system and has lots of usability limitation.

That's where  thin provisioning will shine....

However if you still need to take short-living smallish snapshot and you want 
to use non-provisioned origin device, there the snapshot will still work as 
proven technology -  just no one can expect it will scale for the recent 
device size explosion...

Regards

Zdenek