From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 References: <93bff248-6897-4867-841b-2dace11597de@torlan.ru> <1ec0a220-d5b0-1c27-e63b-c4d3f4ce9d77@torlan.ru> <20180803185431.GB3258@redhat.com> In-Reply-To: <20180803185431.GB3258@redhat.com> From: Linus Torvalds Date: Fri, 3 Aug 2018 12:09:56 -0700 Message-ID: Subject: Re: LVM snapshot broke between 4.14 and 4.16 To: Mike Snitzer Cc: Zdenek Kabelac , wgh@torlan.ru, Ilya Dryomov , Jens Axboe , linux-block , Linux Kernel Mailing List , Sagi Grimberg , dm-devel@redhat.com Content-Type: text/plain; charset="UTF-8" List-ID: On Fri, Aug 3, 2018 at 11:54 AM Mike Snitzer wrote: > > > As I explained to Ted in my previous reply to this thread: using an lvm2 > that is of the same vintage of the kernel is generally going to provide > a more robust user experience You said that yes. And it is completely irrelevant. The fact is, if you use an older lvm2, then a newer kernel still needs to work. Your "more robust experience" argument has nothing what-so-ever to do with that. Will you get new features from newer user land tools? Sure, usually. And entirely immaterial to a kernel regression. Will newer user land tools hopefully fix other issues? You'd hope so, but again - immaterial. So why are you bringing up a complete red herring? It's entirely immaterial to the actual issue at hand. I would _hope_ that other projects hjave the same "no regressions" rule that the kernel has, but I know many don't. But whatever other projects are out there, and whatever other rules _they_ have for their development is also entirely immaterial to the kernel. The kernel has a simple rule: no user regressions. Yes, we've had to break that rule very occasionally - when the semantics are a huge honking security issue and cannot possibly be hidden any other way, then we obviously have to break them. So it has happened. It's happily quite rare. But in this case, the issue is that the block layer now enforces the read-only protection more. And it seems to be the case that the lvm tools set the read-only flag even when they then depended on being able to write to them, because we didn't use to. So just judging from that description, I do suspect that "we can't depend on the lvm read-only flag", so a patch like "let's not turn DM_READONLY_FLAG into actually set_disk_ro(dm_disk(md), 1)" makes sense. Obviously, if we can limit that more, that would be lovely. But dammit, NOBODY gets to say "oh, you should just update user land tools". Because when they do, I will explode. And I'm 1000% serious that I will refuse to work with people who continue to say that or continue to make excuses. And user land developers should damn well know about this. The fact that they are apparently not clued in about kernel rules is what allowed this bug to go undiscovered and unreported for much too long. Apparently the lvm2 user land developers *did* notice the breakage, but instead of reporting it as a kernel bug, they worked around it. So user land developers should actually know that if the kernel stops working for them, they should *not* work around it. Sure, fix your program, but let the kernel people know. And kernel people should know that "oh, the user land people already changed their behavior" is *not* a "I don't need to care about it". Unless the user land fix was so long ago that nobody cares any more. Linus